DTO = ViewModel?

ViewModel in ASP.NET практика MVC такая же, как и DTO, однако ViewModel в шаблоне MVVM отличается от DTO, потому что ViewModel в MVVM имеет поведение, но DTO не имеет.

DTO != ViewModel

на MVVM pattern ViewModel используется для изоляции модели от представления. Для представления модели вы можете использовать простой DTO классы, которые снова сопоставляются с базой данных через, например, NHibernate. Но я никогда не видел класс ViewModel, который моделируется как DTO.. Классы ViewModel в основном имеют поведение, которого нет у DTOs.

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

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

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

http://blog.jpboodhoo.com/CommentView,guid,21fe23e7-e42c-48d8-8871-86e65bcc9a50.aspx

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

Итак, как уже говорилось ДТО!=ViewModel

и

DTO и ViewModel имеют разные цели в жизни

во-первых, основное различие заключается в том, что ViewModel может иметь поведение или методы, которые DTO не должны !!!

во-вторых, используя DTO в качестве ViewModel in ASP.NET MVC делает ваше приложение тесно связанным с DTO, и это именно противоположная цель использования DTO. Если вы это сделаете, в чем разница с использованием вашей модели домена или DTO, больше сложности для получения анти-шаблона ?

также ViewModel in ASP.NET можно использовать DataAnnotations для проверки.

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

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

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

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

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

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

лучше использовать DTO и конвертировать в viewmodel.