Как эффективно использовать объекты DTO (Объекты передачи данных)?

Question

Каков наилучший способ внедрения DTO?

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

Как насчет других вариантов, например, просто отправки данных в качестве параметров метода?(Было бы проще всего сделать это в asces, когда требуется отправить меньше данных?)

Как насчет статического класса, который просто хранит данные, на которые могут ссылаться другие объекты (своего рода глобальный класс хранения данных asembly)?(Не слишком ли сильно это нарушает инкапсуляцию?)

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

Спасибо, что поделились своими мыслями.

Answer 1

Спасибо за все полезные идеи...

Краткое изложение + мой взгляд на это:

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

--Если данных и / или объектов для их перемещения много, проще всего использовать специально созданный объект (объект DTO).

--Глобальный объект данных, на который могут ссылаться (а не передаваться) различные объекты, казалось бы, не одобряется ... однако, мне интересно, иногда ли для него нет места в конкретной подсистеме?Это один из способов уменьшить объем передаваемых данных.Это действительно расширяет границы "хорошей инкапсуляции", однако в конкретных случаях в определенных слоях, возможно, это могло бы добавить простоты частичной сборке классов.Таким образом, можно было бы потерять инкапсуляцию на уровне класса, но все равно иметь инкапсуляцию на уровне сборки.

Answer 2

Я использовал DTO, чтобы:

• Передача данных между пользовательским интерфейсом и уровнями обслуживания стандартного 3-уровневого приложения.
• Передайте данные в качестве параметров метода для инкапсуляции большого количества (более 5) параметров.

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

Я никогда не видел статических DTO в том виде, в каком вы упоминаете, и колебался бы при создании одиночных DTO, как вы описываете.

Answer 3

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

Answer 4

Я хотел бы, чтобы все было так же просто.Хотя DTO возникает из-за сетевых уровней распределения системы, может возникнуть целый ряд проблем, если объекты домена будут возвращены на уровни просмотра.Вот некоторые из них:

1.By отображая объекты домена на уровне просмотра, представления узнают о структуре объектов домена, что позволяет view делать некоторые предположения о том, как доступны связанные объекты.Например, если доменный объект "Person" был повторно настроен на представление, к которому он "привязан", а в каком-то другом представлении должен быть привязан "Адрес" Person, на прикладном уровне была бы тенденция использовать семантику, подобную person.getAddresse(), что привело бы к сбою, поскольку в этот момент доменный объект Address, возможно, не был загружен в данный момент.По сути, когда объекты домена становятся доступными для просмотра слоев, представления всегда могут делать предположения о том, как становятся доступными данные.

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

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

Очевидно, что для этого нет правильных ответов, особенно в толстой клиентской системе.

Я позаимствовал этот короткий и не полный, но верный ответ на клише DTO у:
http://www.theserverside.com/discussions/thread.tss?thread_id=32389#160505

Answer 5

Я думаю, что довольно распространено использовать DataSet / DataTable в качестве "единого DTO для управления ими всеми".Их легко загрузить из базы данных и сохранить значения обратно, и они могут быть легко сериализованы.

Я бы определенно сказал, что использовать их сложнее.Они действительно предоставляют все необходимые услуги, но программирование против них сопряжено с трудностями (множество приведений, нулевых проверок, волшебных строк и т.д.).Было бы интересно увидеть хороший набор методов расширения, чтобы сделать работу с ними немного более "естественной".

Answer 6

DTO используются для передачи данных по проводам, а не между объектами.Ознакомьтесь с этим постом:POCO vs DTO