Об объектах данных и DAO Design при использовании Hibernate

Question

Я колеблюсь между двумя проектами проекта базы данных с использованием Hibernate.

Дизайн # 1.

(1) Создайте общий интерфейс поставщика данных, включая набор интерфейсов DAO иобщие классы контейнера данных.Это скрывает нижнюю реализацию.Реализация поставщика данных может получить доступ к данным в базе данных, или к XML-файлу, или к сервису, или к чему-то еще.Пользователь поставщика данных не должен знать об этом.

(2) Создайте библиотеку базы данных с помощью Hibernate.Эта библиотека реализует интерфейс поставщика данных в (1).

Плохая вещь в Design # 1 состоит в том, что для того, чтобы скрыть детали реализации, мне нужно создать два набора классов контейнера данных.Один в общем интерфейсе провайдера данных - назовем их DPI-объектами, другой набор используется в библиотеке базы данных, исключительно для отображения сущностей / атрибутов в Hibernate - давайте назовем их H-объектами.В реализации DAO мне нужно прочитать данные из базы данных, чтобы создать H-объекты (через Hibernate), а затем преобразовать H-объекты в DPI-объекты.

Design # 2.

Несоздать общий интерфейс поставщика данных.Выставляйте H-объекты напрямую компонентам, которые используют базу данных lib.Поэтому пользователю библиотеки базы данных необходимо знать о Hibernate.

Мне больше нравится дизайн # 1, но я не хочу создавать два набора классов контейнера данных.Это правильный способ скрыть H-объекты и другие детали реализации Hibernate от пользователя, который использует поставщика данных на основе базы данных?

Есть ли какие-либо недостатки в Design # 2?Я не буду внедрять других поставщиков данных в будущем, поэтому я должен просто забыть об интерфейсе поставщиков данных и использовать Design # 2?

Что вы думаете об этом?Спасибо за ваше время!

Answer 1

Объекты Hibernate Domain - это простые POJO, поэтому вам не нужно создавать отдельные DPI-объекты, сами H-Object можно использовать напрямую. В DAO вы можете контролировать, приходят ли они из спящего режима или из чего-либо еще.

Answer 2

Я настоятельно рекомендую прочитать главу 4 «Попадание в базу данных» Spring in Action, 3-е издание , даже если вы не используете Spring в своем приложении. Хотя моя вторая рекомендация будет использовать Spring :-)

Шаблон DAO - отличный способ сохранить базу данных и логику ORM изолированными в реализации DAO, и вам нужен только один набор объектов сущностей. Вы можете сделать это без Spring, просто требуется больше работы по управлению вашими сессиями и транзакциями.

Если я понимаю ваш пост, это своего рода промежуточное звено между Проектом 1 и Проектом 2. H-объектам (сущностям, которые спят в Hibernates, загружаются и сохраняются) вообще не нужен какой-либо специальный код Hibernate. Это делает их совершенно приемлемыми для использования в качестве ваших объектов DPI.

В прошлом у меня были споры с людьми, которые жалуются, что использование JPA или Hibernate Annotations раскрывает особенности Hibernate через интерфейс DAO. Лично я придерживаюсь более прагматичного взгляда, поскольку аннотации являются просто метаданными и не напрямую влияют на работу ваших классов сущностей.

Если вы чувствуете, что аннотации слишком много раскрывают, тогда вы можете перейти к старой школе и использовать Hibernate Mappings . Тогда ваши H-объекты на 100% свободны от Hibernate: -)

Answer 3

Я рекомендую дизайн № 2. Просто создайте доменные объекты, и пусть Hibernate присматривает за ними. Не пишите отдельные классы, которые сохраняются.

Hibernate пытается скрыть от вас большую часть персистентного бизнеса. Возможно, вам придется добавить несколько небольших аннотаций к вашим сущностям, чтобы помочь ему в этом. Но, конечно, не делайте отдельных классов.

Возможно, вам понадобятся очень маленькие классы DAO. Например, если у вас есть сущность Person, было бы довольно распространенной практикой иметь объект PersonDAO, который сохраняет личность. Сказав это, код внутри DAO будет очень простым, поэтому для действительно небольшого проекта это может не стоить того. Для большого проекта, вероятно, стоит сохранить свой код персистентности отдельно от бизнес-логики, если вы захотите позже использовать другую технологию персистентности.