Почему объекты передачи данных (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 Spec делает модель Bean Bean такими же, как и простые старые 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 становится необходимостью, а не АНТИ-ШАБЛОНОМ, когда все объекты вашего домена загружают связанные объекты с готовностью.

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

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

Answer 9

Намерение Объект передачи данных заключается в хранении данных из разных источников и последующей передаче их в базу данных (или Удаленный фасад) однажды.

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

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

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

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

Answer 10

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

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

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

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

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

Answer 11

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