DTO = ViewModel?

Я использую NHibernate для сохранения объектов домена. Чтобы все было просто, я использую проект ASP.NET MVC как для моего уровня представления, так и для моего уровня обслуживания.

Я хочу вернуть объекты домена в XML из своих классов контроллера. После прочтения некоторых сообщений здесь о переполнении стека я собираю DTO. Тем не менее, я также встречаю сообщения о ViewModel.

Мой вопрос: Являются ли объекты передачи данных и ViewModels одинаковыми? Или является ViewModel своего рода подструктурой DTO?

Ответ 1

Каноническое определение DTO - это форма данных объекта без какого-либо поведения.

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

Кстати, NHibernate projections пригодится, если определенной модели просмотра требуется подмножество данных из сохраняемого объекта.

Ответ 2

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

Ответ 3

DTO!= ViewModel

В MVVM шаблон ViewModel используется для выделения Модели из представления. Чтобы представить модель, вы можете использовать простые классы

Ответ 4

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

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

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

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

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

Так снова, как уже было сказано, DTO!= ViewModel

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

Ответ 5

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

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

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

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

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

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

Ответ 6

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

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

Ответ 7

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

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