Является ли шаблон DTO устаревшим или нет?

В полном приложении Java EE, которое кластерировано, является шаблоном DTO по-прежнему действительным вариантом? В рассматриваемом приложении используется Hibernate и Struts EJB с Spring и т.д. Есть ли что-то не так с переносом объектов домена в таком сценарии?

EDIT: просто для того, чтобы уточнить мой вопрос, с современными ресурсами дня и улучшениями в Java EE существует ли причина не просто использовать объекты домена? Если это не так, то тип DTO не исчезает и не должен использоваться в новых приложениях?

ОТВЕТЫ

Ответ 1

Не устарел. Это зависит от архитектуры приложения, если использовать шаблон DTO или нет. Например, при разработке веб-сервисов (с использованием JAX-WS или JAX-RS) вы должны отправить DTO через свои веб-методы, чтобы клиентское приложение С# или Python могло его использовать, и ваш веб-метод не должен возвращать объект, класс которого Hibernate аннотации, помните, чем на других языках Entity не будет создан с этими аннотациями или другой бизнес-логикой внутри.

EDIT (основывается на ваших комментариях): Это зависит от архитектуры программного обеспечения. Например, я работаю над SOA-проектом, и мы используем DTO для уровня обслуживания и уровня представления. Чем глубже внутри, мы даже используем DTO для обработки связи с базой данных внутри сервисов, мы используем только SP для связи с БД, поэтому ни один Hibernate или любые другие инструменты ORM не могут там работать, мы могли бы использовать Spring DAO, и эта структура также использует DTO. Во многих приложениях вы можете найти множество шаблонов DTO.

Дополнительная информация, которая будет полезна для этого вопроса:

EDIT 2: Еще один источник информации, который объяснит основную причину использования дизайна DTO, объясненную Martin Fowler

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

Ответ 2

Это очень полезный шаблон в Java EE.

Я использую DTO для переноса связанных объектов объекта из EJB beans в слой пользовательского интерфейса. Объекты сущности извлекаются из DB в одной транзакции (см. TransactionAttributeType.REQUIRED) и сохраняются в объекте DTO. DTO потребляется в слое пользовательского интерфейса.

Ответ 3

Образец - чистый дизайн. Нет "устаревания" шаблона, но меньше времени использования (или чрезмерного использования).
Лично я не понимаю, почему бы не использовать DTO.
Например, при oVirt проекте с открытым исходным кодом у нас есть сущности, представляющие объекты бизнес-логики в области виртуализации.
Эти объекты должны быть либо аннотированы аннотациями Hibernate (фактически, они есть сегодня, так как мы начали работать с HOC), и выполняем функции DTO, а затем очищаем от объектов аннотаций, которые будут отображаться на них (скажем, используя dozer framework) и используется клиентом
 (Мне не нравится иметь код на стороне клиента с ненужными аннотациями), или сущности должны выступать в качестве объектов-клиентов (объектов значений), переданных клиенту, и мы должны иметь другие классы в качестве объектов DTO

Минус в приведенном выше подходе состоит в том, что у вас могут быть две параллельные диаграммы классов - одна для DTO и одна для объектов значений (которые используются клиентами) - но во многих случаях в дизайне есть компромисс.
Вы должны понимать преимущества и недостатки и выбирать то, что лучше для вас (в нашем случае, поскольку клиентская сторона - это GWT, нам будет легче перейти на разделение на две иерархии классов: на стороне DTO/server и также аннотируется с дополнительными аннотациями на стороне сервера, а другой - клиентом кода GWT).