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

Question

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

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

Answer 1

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

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

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

Answer 2

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

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