Как использовать DTO в JSF + Spring + Hibernate - PullRequest
5 голосов
/ 20 апреля 2011

Предполагая, что я новичок в теме DTO. Я не могу понять, правильно ли использовать DTO в тандеме с JSF, Spring и Hibernate.
Позвольте мне объяснить, до сих пор я использовал компонент управления данными, созданный непосредственно из базы данных, как на бизнес-уровне, так и на уровне представления. Теперь я решил попробовать использовать подход DTO, но я не могу понять, как они могут помочь.
Например, если у меня есть два класса User и Message, и у пользователя есть больше связанных сообщений; Как я могу заполнить DTO из базы данных? Или я вручную заполняю DTO на бизнес-уровне? Может кто-нибудь опубликовать пример использования DTO?

Спасибо заранее. С Уважением, Roberto

Ответы [ 2 ]

16 голосов
/ 20 апреля 2011

DTO обозначает Объект Передачи Данных.Предполагается, что это простой ванильный класс Javabean без каких-либо специфических ограничений API / архитектуры, таких как аннотации JSF, JPA или Spring.Т.е. он не должен содержать никаких import или FQN, указывающих на внешний API.Единственная цель - передавать данные между различными архитектурами большого модульного веб-приложения.

Например, если вы не хотите использовать объектный компонент JPA / Hibernate в качестве свойства модели управляемого JSF-компонента и представления, потому что они не могут быть переданы за пределы класса EJB из-за чрезмерно ограничительного бизнеса илиИз соображений модульности, вам нужно создать копию этого класса и сопоставить свободные свойства самостоятельно.В основном:

UserEntity userEntity = em.find(UserEntity.class, id);
UserDTO userDTO = new UserDTO();
userDTO.setId(userEntity.getId());
userDTO.setName(userEntity.getName());
// ...
return userDTO;

Имеется множество библиотек , которые упрощают сопоставление bean-to-bean следующим образом:

SomeLibary.map(userEntity, userDTO);

Однако для среднеговеб-приложение вам не нужно DTO.Вы уже используете объекты JPA.Вы можете просто использовать их в своем компоненте / представлении JSF.

Один этот вопрос уже указывает на то, что на самом деле вам вообще не нужны DTO.Вы не заблокированы некоторыми конкретными бизнес-ограничениями.Тогда вам не следует искать шаблоны проектирования, чтобы вы могли применить их в своем проекте.Вы должны скорее искать реальные проблемы в виде слишком сложного / не поддерживаемого / дублированного кода, чтобы вы могли спросить / найти подходящий шаблон дизайна для него.Обычно рефакторинг дублирующего кода почти автоматически вводит новые шаблоны проектирования, даже если вы этого не понимаете.

Хорошим примером является случай, когда сущность JPA «слишком велика» для конкретной цели (т.е. сущность содержит гораздо больше свойств, чем вам действительно нужно).Наличие большого количества этих частично используемых объектов - пустая трата памяти сервера.Чтобы решить эту проблему, вы можете создать класс / подкласс DTO на основе только нескольких его свойств, которые вы создаете и заполняете, используя выражение конструктора в JPQL.

См. Также:

11 голосов
/ 20 апреля 2011

Существует два варианта заполнения DTO - вручную или с помощью такой утилиты, как commons-beanutils или Dozer.

Общая идея DTO заключается в том, что они используются для передачи данных между уровнями архитектуры - чаще всего слоями, которые слабо связаны, например, через веб-сервисы или JMS. DTO также могут использоваться в представлениях, так что веб-слой получает объекты, которые он может использовать для отображения пользователю, и они отличаются от сущностей, чтобы избежать проблем управления состоянием сущностей и отображения ошибок.

Но для типичного приложения я бы сказал, что DTO не нужны. Используйте свои сущности в ваших bean-компонентах и ​​представлениях JSF, просто будьте осторожны с возможными LazyInitializationException. Мой опыт показывает, что сущности могут быть использованы в качестве DTO (без необходимости нового класса) в большинстве случаев, с немного большей осторожностью. И везде, где я видел DTO в небольших проектах, они только усложняли вещи.

...