Должны ли необработанные аннотированные POJO Hibernate возвращаться с уровня доступа к данным или с интерфейсов?

Я понимаю разделение объектов уровня данных (DAO) на их собственном уровне, который абстрагирует логику доступа к данным и особенности источника данных от сервисного и бизнес-уровней, как описано в Уровни DAO и Service (JPA / Hibernate + Spring) и другие вопросы. У меня есть опыт создания этих слоев, но я всегда использовал либо необработанный JDBC, либо аналогичные низкоуровневые способы взаимодействия с БД (например, Spring SimpleJDBC), и я новичок в Hibernate.

Мой вопрос заключается в том, что в необработанном JDBC или другими способами, когда вы фактически имеете дело с набором результатов (или тонкой оболочкой вокруг него) на уровне доступа к данным, полученные POJO, в которые вы вставляете свои данные, чрезвычайно чисты и ничего не знают о том, где данные были получены, и я никогда не беспокоился о том, чтобы вернуть их на уровень обслуживания и далее. Однако похоже, что с Hibernate у вас есть много вашей специфической логики Hibernate / структуры данных прямо в аннотациях POJO (такие вещи, как сопоставления от 1 до многих, настройки отложенной загрузки и т. Д.). Мне неудобно возвращать их (или их коллекции) из моих DAO на мой уровень обслуживания, и я испытываю искушение, чтобы все POJO реализуют интерфейсы, которые я передаю обратно. Это хорошая практика или это слишком сложно?


person Peter    schedule 21.10.2011    source источник


Ответы (2)


У аннотаций есть один недостаток, связанный с объединением некоторых знаний фреймворка с объектами Java. Это цена, которую вы платите за отсутствие отдельных определений метаданных. Однако POJO по-прежнему остаются POJO, и с практической точки зрения я не вижу веских причин для усложнения дизайна только из-за аннотаций.

Давайте подумаем, если бы вы использовали сопоставления XML, возникло бы у вас такое беспокойство? Скорее всего - нет. Так что заплатите штраф и двигайтесь дальше; и в маловероятном случае, если вы измените свою структуру персистентности, вы удалите эти аннотации. Во всех случаях они не должны иметь побочных эффектов для вашего кода за пределами вашего уровня DAO.

Только мои 2 цента ...

person Alex Gitelman    schedule 22.10.2011
comment
Взвесив все «за» и «против», я согласен. Что касается доступа к данным только для чтения, мне нравится идея интерфейса, но переход от интерфейсов обратно к pojos, которые знают, как хранить себя для сохранения через отражение или подобное, слишком болезненно. - person Peter; 24.10.2011

Оба;) Я довольно амбивалентен - я предпочитаю интерфейсы, их проще имитировать, использовать в системах без Hibernate и т. Д., Но в моем случае мне обычно нужно было предоставить внешний API с типами данных, так что это почти всегда имело смысл. Это, и я автоматически генерирую интерфейсы, поэтому мне не нужно на самом деле ничего делать.

Я не уверен, что для изолированных систем без требований внешнего API или если вам никогда не нужны типы, отличные от Hibernate, это действительно так важно, хотя пуристы будут кричать об этом (а они возможно, правильно).

person Dave Newton    schedule 21.10.2011
comment
Дэйв, при использовании интерфейсов и принятии данных от уровня сервиса для сохранения на уровне доступа к данным, в какой момент и как вы обрабатываете создание POJO? у вас есть фабрика, которая переходит от интерфейса к POJO? - person Peter; 22.10.2011
comment
@ Пит зависит. Внутри приложения я часто просто передаю объекты Hibernate / JPA, потому что это просто не стоит усилий, чтобы делать что-либо еще. Когда я это делаю, я использую что-то вроде BeanUtils Apache Commons, которые содержат методы копирования отражающих свойств; средства для создания экземпляров объектов различаются. - person Dave Newton; 22.10.2011