it-swarm.com.ru

Почему объекты передачи данных (DTO) являются антишаблоном?

Недавно я слышал, как люди говорили, что объекты передачи данных (DTO) являются антишаблоном .

Зачем? Какие есть альтернативы?

120
ntownsend

Некоторые проекты имеют все данные дважды. Один раз как объекты домена и один раз как объекты передачи данных.

Это дублирование требует огромных затрат, поэтому архитектура должна получить огромную выгоду от такого разделения, чтобы оно того стоило.

122
KLE

DTO не являются антишаблоном. Когда вы отправляете некоторые данные по сети (например, на веб-страницу в вызове Ajax), вы хотите быть уверены, что вы сохраняете пропускную способность, отправляя только те данные, которые будут использоваться адресатом. Кроме того, часто для уровня представления данных удобно иметь данные в несколько ином формате, чем собственный бизнес-объект.

Я знаю, что это вопрос, ориентированный на Java, но в языках .NET анонимные типы, сериализация и LINQ позволяют создавать DTO "на лету", что сокращает затраты на установку и накладные расходы на их использование.

118
Gabe Moothart

DTO AntiPattern в EJB 3. говорит:

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

23
aem

Я не думаю, что DTO сами по себе являются анти-паттернами, но есть антипаттерны, связанные с использованием DTO. Билл Дадни ссылается на взрыв DTO в качестве примера:

http://www.softwaresummit.com/2003/speakers/DudneyJ2EEAntiPatterns.pdf

Есть также ряд злоупотреблений DTO, упомянутых здесь:

http://anirudhvyas.com/root/2008/04/19/abuses-of-dto-pattern-in-Java-world/

Они возникли из-за трехуровневых систем (обычно использующих EJB в качестве технологии) в качестве средства передачи данных между уровнями. Большинство современных систем Java, основанных на таких средах, как Spring, используют альтернативное упрощенное представление с использованием POJO в качестве объектов домена (часто аннотируемых с помощью JPA и т.д.) На одном уровне ... Использование DTO здесь ненужным.

17
Jon

Пуристы OO сказали бы, что DTO является анти-паттерном, потому что объекты становятся представлениями таблицы данных вместо реальных объектов домена.

13
Darin Dimitrov

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

Эта статья смутно описывает некоторые злоупотребления.

7
Ben S

Если вы строите распределенную систему, то DTO, безусловно, не являются антишаблоном. Не все будут развиваться в этом смысле, но если у вас есть (например) приложение Open Social, работающее на JavaScript.

Он разместит загрузку данных в вашем API. Затем он десериализуется в некоторый вид объекта, обычно объект DTO/Request. Затем это можно проверить, чтобы убедиться, что введенные данные верны перед преобразованием в объект модели.

На мой взгляд, это рассматривается как анти-шаблон, потому что он используется неправильно. Если вы не строите распределенную систему, скорее всего, они вам не нужны.

6
Bealer

DTO становится необходимостью, а не АНТИ-ШАБЛОНОМ, когда все ваши доменные объекты загружают связанные объекты EAGERly.

Если вы не создадите DTO, у вас будут ненужные объекты, перенесенные с вашего бизнес-уровня на ваш клиентский/веб-уровень.

Чтобы ограничить накладные расходы в этом случае, лучше перенести DTO.

4
javadev

Цель Data Transfer Object состоит в том, чтобы сохранить данные из разных источников и затем сразу перенести их в базу данных (или Remote Facade ).

Однако шаблон DTO нарушает Принцип единой ответственности, поскольку DTO не только хранит данные, но и передает их из или в базу данных/фасад.

Необходимость отделять объекты данных от бизнес-объектов не является антипаттерном, поскольку, вероятно, в любом случае требуется отделить слой базы данных .

Вместо DTO вы должны использовать Aggregate и Repository Patterns, которые разделяют коллекцию объектов ( Aggregate ) и передачу данных ( Repository ).

Для передачи группы объектов вы можете использовать шаблон nit Of Work , который содержит набор репозиториев и контекст транзакции; для передачи каждого объекта в совокупности отдельно в рамках транзакции.

3
MovGP0

Вопрос должен быть не "почему", а "когда".

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

Это не анти-паттерн, когда вам действительно нужно другое представление классов домена - более плоский, более богатый, более узкий, ...

Лично я начинаю с класса домена и прохожу его с правильной проверкой в ​​нужных местах. Я могу аннотировать и/или добавлять некоторые "вспомогательные" классы для создания отображений, базы данных, форматов сериализации, таких как JSON или XML ... Я всегда могу разделить класс на два, если я чувствую необходимость.

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

2
Rostislav Matl

Я думаю, что люди подразумевают, что это может быть анти-паттерном, если вы реализуете все удаленные объекты как DTO. DTO - это просто набор атрибутов, и если у вас есть большие объекты, вы всегда будете передавать все атрибуты, даже если они вам не нужны или не используются. В последнем случае предпочитают использовать шаблон Proxy.

0
jdehaan