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

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

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

107 голосов | спросил ntownsend 17 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 17 Sep 2009 23:46:34 +0400 2009, 23:46:34

11 ответов


0

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

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

ответил KLE 17 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 17 Sep 2009 23:54:53 +0400 2009, 23:54:53
0

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

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

ответил Gabe Moothart 18 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 18 Sep 2009 00:00:19 +0400 2009, 00:00:19
0

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

  

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

ответил aem 17 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 17 Sep 2009 23:54:23 +0400 2009, 23:54:23
0

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

ответил Jon 17 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 17 Sep 2009 23:54:32 +0400 2009, 23:54:32
0

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

ответил Darin Dimitrov 17 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 17 Sep 2009 23:52:18 +0400 2009, 23:52:18
0

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

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

ответил Ben S 17 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 17 Sep 2009 23:53:45 +0400 2009, 23:53:45
0

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

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

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

ответил Bealer 18 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 18 Sep 2009 04:10:03 +0400 2009, 04:10:03
0

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

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

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

ответил javadev 26 +03002015-10-26T18:43:37+03:00312015bEurope/MoscowMon, 26 Oct 2015 18:43:37 +0300 2015, 18:43:37
0

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

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

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

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

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

ответил MovGP0 22 MonEurope/Moscow2014-12-22T14:43:49+03:00Europe/Moscow12bEurope/MoscowMon, 22 Dec 2014 14:43:49 +0300 2014, 14:43:49
0

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

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

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

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

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

ответил Rostislav Matl 22 PM00000060000003431 2018, 18:32:34
0

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

ответил jdehaan 17 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 17 Sep 2009 23:52:30 +0400 2009, 23:52:30

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132