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

Question

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

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

Answer 1

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

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

Answer 2

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

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

Answer 3

DTO Антипаттерн в EJB 3.0 говорит:

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

Answer 4

Я не думаю, что 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 здесь не требуется.

Answer 5

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

Answer 6

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

В этой статье смутно описаны некоторые злоупотребления.

Answer 7

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

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

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

Answer 8

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

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

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

Answer 9

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

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

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

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

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

Answer 10

Вопрос должен быть не «почему», а « при ».

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

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

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

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