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

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

DTO AntiPattern в EJB 3.0 говорит:

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

Ответ 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 здесь не нужно.

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

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

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

Ответ 8

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

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

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

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

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

Ответ 9

DTO становится необходимостью, а не ANTI-PATTERN, когда все объекты вашего домена загружают связанные объекты EAGERly.

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

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

Ответ 10

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