JPA POJO как объект данных

Question

Какова наилучшая практика использования объектов JPA?

Поскольку объекты JPA являются просто POJO, считается ли целесообразным использовать объект в качестве объекта данных в других частях системы или я должен преобразовать их в другой объект данных?

Допустимо ли использование объектов POJO JPA в других частях системы, не связанных с JPA?

Answer 1

Сами сущности теперь способны переносить свои собственные данные, так зачем их преобразовывать во что-то еще? Другими словами, я склонен согласиться с DTO AntiPattern в EJB 3.0 :

Тяжелый вес сущностных компонентов в спецификациях EJB до EJB 3.0 привел к использованию шаблонов проектирования, таких как Объекты передачи данных (DTO). DTO стали легковесными объектами (которые должны были быть в первую очередь самими компонентами), используемыми для отправки данных по уровням. [...]

Спецификация EJB 3.0 делает модель бина Entity такой же, как и простой старый объект Java (POJO). С этой новой моделью POJO вам больше не нужно будет создавать DTO для каждого объекта или для набора объектов. Если вы хотите отправлять сущности EJB 3.0 через уровень, сделайте так, чтобы они реализовали java.io.Serialiazable.

Answer 2

Это хороший вопрос.

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

Будущие изменения в устойчивости системы могут быть невозможными, неудобными, ограниченными и / или рискованными. Пример: вам может потребоваться оптимизировать производительность и / или масштабируемость. Это может потребовать кеширования, изменений схемы БД, не использования СУБД, нескольких баз данных. Инкапсуляция также помогает уменьшить миграцию в будущие схемы БД.

Итак, компромисс:

• управление и поддержание уровня персистентности приложения поверх JPA, который инкапсулирует персистентность. то есть интерфейс. ИЛИ
• решите использовать JPA по всем направлениям в вашей архитектуре. Примите тот факт, что будущие изменения могут иметь общесистемные последствия.

Первый вариант может быть необходим, если частые изменения в масштабе всей системы неприемлемы - например, Третьи лица получают доступ к вашим данным. Или, возможно, вы выбрали трехуровневую архитектуру: GUI, бизнес-логика, постоянство.

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

Answer 3

Это зависит от того, что вы имеете в виду под «другими частями». Поскольку ваши сущности JPA должны быть как-то связаны с вашей системой, почему бы не использовать их, поскольку они уже есть. Важным моментом является то, что вы не используете один и тот же класс для двух совершенно разных задач (что в свою очередь является признаком плохого дизайна или просто очень большой системы). Все остальное, вероятно, просто закончится бесконечным сопоставлением между вашими хлопотами с различными POJO.

Например, Логин пользователя. Может быть распространенной многословной практикой Java создание отдельного компонента UserLoginForm для входа в систему через Интернет, но учтите следующее:

У вас уже есть ваши пользовательские сущности JPA (и, следовательно, пользователь POJO) в базе данных (в ней хранятся имя пользователя, хэш пароля, адрес и, возможно, другие вещи). Вы также можете использовать точно такой же объект в своем запросе на вход в систему из веб-формы (некоторые фреймворки, такие как Spring, отображают его сразу). Создайте пустой объект User, задайте имя пользователя и хешированный пароль и создайте JPA-запрос в качестве примера. Если этот запрос возвращает ровно один результат, логин действителен, и вы можете сохранить загруженный объект пользователя в сеансе.