Гибернация: от наследства к композиции - PullRequest
1 голос
/ 25 июля 2011

У меня есть модель предметной области, которая в настоящее время в значительной степени зависит от наследования, и из-за нескольких проблем, связанных с прокси-моделью Hibernate, я реорганизую модель для использования композиции вместо нее. Основной проблемой, с которой я столкнулся, является следующая ситуация:

  1. Получить запись X в качестве родителя
  2. Hibernate возвращает прокси для Родителя
  3. instance of и уныние теперь сломано

Кроме того, такие вещи, как ссылки внешнего ключа на родительскую таблицу, не будут работать с таблицей для конкретной стратегии подкласса. Так что теперь я в основном делаю Parent конкретным классом и помещаю ссылку на Child1 и Child2 в родительский класс (требуется соединение для извлечения данных по мере необходимости).

На основании этого описания кто-нибудь шел по подобному пути и сталкивался с какими-либо проблемами, или этот подход имеет смысл? Есть ли лучший подход, о котором я не думал?

Ответы [ 2 ]

1 голос
/ 26 июля 2011

Если я правильно вас понял, в вашем примере parent - это суперкласс, а child1 и child2 - это подклассы.В большинстве случаев композиция - лучший выбор, поэтому, поскольку я не знаю деталей вашей модели, я бы сказал, что вы на правильном пути.Однако я думаю, что было бы лучше, если бы ваши child1 и child2 имели ссылку на parent, потому что они «расширяют» parent.Родитель даже не должен знать, что он расширен, поэтому у родителя не должно быть ссылки на потомков.

1 голос
/ 25 июля 2011

Мне никогда не приходилось переходить с одного на другое, но я испытал оба типа, и вы движетесь в правильном направлении. Проблема заключается в том, что instanceof и downcasting, используемые таким образом, нарушают полиморфизм, который, как предполагает Hibernate, вы используете вместо подрывной деятельности. Переход к истинно объектно-ориентированной модели - это шаг в правильном направлении.

...