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

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

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

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

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

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

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

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

В этой статье расплывчато описаны некоторые нарушения.

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

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

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

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