Как эффективно использовать DTO-объекты (Data Transfer Objects)?

Question

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

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

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

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

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

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

Answer 1

Я использовал DTO для:

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

Answer 6

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

Резюме + мой взгляд на это:

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

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

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