Разбить большую модель Hibernate для управления зависимостями схемы - PullRequest
1 голос
/ 21 сентября 2010

Мы рассматриваем разбиение наших таблиц гибернации на пакеты или домены (выставление счетов, продажи, ... и т. Д.), Главным образом для решения проблем управления зависимостями.

Конечно, это не очень аккуратно, поэтому мы не уверены, как обращаться с отношениями, которые пересекают домены. Было бы неплохо иметь для этого новую аннотацию сущности, но в то же время одна идея состоит в том, чтобы сделать несколько копий модели, в которой есть некоторые различия в том, как аннотируются отношения, чтобы «оторвать свободные концы». Эти измененные объекты, вероятно, нужно будет сделать «доступными только для чтения» в других моделях, к которым они не принадлежат. Кроме того, некоторое время мы будем продолжать использовать существующую полную модель, когда будем переводить приложения на более мелкие.

Так, например, большинство таблиц должно полностью существовать в той или иной модели; но если Domain1.Table1 относится к Domain2.Table2, вы должны сделать копию только для чтения каждого в домене другого. У копии будут другие отношения в его домене, которые будут заменены на «тупики» (возможно, путем замены ссылок отношений на целочисленный ссылочный атрибут fk).

Дело в том, что мы хотели бы иметь какой-то способ управления нашими сборками maven, чтобы при изменении атрибута таблицы мы объявили зависимости только от модели этого домена, чтобы мы могли уменьшить количество приложений, которые должны быть восстановлены. (у нас жесткие окна отключения при развертывании).

О, и все домены должны использовать один и тот же Java-пакет для совместимости с нашим устаревшим EJB-инструментом персистентности

Так вот в чем идея. Любые предложения / отзывы / комментарии? Спасибо!

1 Ответ

0 голосов
/ 22 января 2011

Вы предлагаете скопировать сущности связанной таблицы в требуемые домены (не в домен), а затем изменить ее собственные доменные зависимости в «тупики», то есть значения Integer FK, которые потенциально могут использоваться для поиска в случае необходимости.

Мое предложение: вы должны делать это на границе каждого домена и ничего не копировать.Так что, если Domain1.Table1 относится к Domain2.Table2, у него просто есть FK, поля int могут называться table2Id.Это создало бы тупики на краю каждого домена вместо необходимости пересечения и дублирования.

Я должен спросить, хотя ...

Вы уверены, что у вас есть несколько доменов?

Кажется, корень вашей проблемы в том, что ваши данные связаны, что указывает на то, что они являются частью одного домена.Например, вы говорите о продажах и выставлении счетов-фактур как об отдельных доменах, но они, вероятно, оба делятся отзывами клиентов.Все это чувствует, как будто это принадлежит мне.Домены / отрасли некоторых проектов велики, и их разбивка для удобства и простоты, как правило, в конечном итоге является ошибкой и часто добавляет непредвиденную сложность.Например, если вам нужно выполнить поиск по продаже, в котором должна быть ссылка на счет, но вместо этого теперь вам нужно выполнить отдельный поиск по счету, это делает использование клиентов вашего API немного тяжелым.

...