В чем разница между моделью представления и объектом передачи данных?

Question

Я основываю этот вопрос на Фаулере PoEAA. Учитывая ваше знакомство с этим текстом, не являются ли ViewModels, используемые в ASP.NET MVC, такими же, как DTO? Почему или почему нет? Спасибо.

Answer 1

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

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

  Например, вы разрабатываете сайт электронной коммерции. CreateCustomer а также AddCustomerAddress это отдельные операции на уровне базы данных, но вы можете по соображениям производительности объединить их данные в NewCustomerWithAddressDto так что вашему клиенту нужно всего лишь совершить одну поездку на сервер, и ему не нужно заботиться о том, что сервер может делать кучу разных вещей с пакетом данных.

• Термин "ViewModel" означает несколько разные вещи в разных вариантах MV*, но его целью является главным образом разделение интересов. Ваша Модель часто оптимизируется для какой-либо другой цели, кроме презентации, и ViewModel несет ответственность за отделение вашего Представления от деталей реализации Модели. Кроме того, большинство шаблонов MV * рекомендуют делать ваши представления как можно более "тупыми", и поэтому ViewModel иногда берет на себя ответственность за логику представления.

  Например, в том же приложении электронной коммерции ваш CustomerModel неправильная "форма" для представления в вашем представлении "Новый клиент". Для начала в вашем представлении есть два поля формы, в которые пользователь может ввести и подтвердить свой пароль, и ваш CustomerModel не содержит поля пароля вообще! Ваш NewCustomerViewModel будет содержать эти поля и может, в зависимости от вашего вида MV*, отвечать за некоторую логику представления (например, чтобы показать / скрыть части представления) и за базовую проверку (например, обеспечение соответствия обоих полей пароля).

Answer 2

Цель другая:

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

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

Answer 3

DTO в MVVM и MVP, как правило, являются очень тупыми объектами и представляют собой просто наборы установщиков и получателей свойств. ViewModels, с другой стороны, может иметь некоторое поведение.

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

Answer 4

Модель представления и объект Data Transfer имеют сходства и различия.

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

Разница: модель представления предназначена для отправки в представление, где оно будет отображаться, с форматированием. Модель представления также отправляет данные обратно в контроллер. DTO обычно не предназначен для презентации. Он предназначен для отправки необработанных данных.

Answer 5

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

В этом случае вы должны создать «псевдо» DTO, которые объединяют 2 или более других DTO вместе для передачи данных в одной «модели» методу или API и т. д. Однако я никогда не придумывал соглашение об именах для этих «псевдо» DTO, поэтому просто добавил к ним суффикс «DTO», но поместил их в папку моделей вместе с моделями просмотра ‍♂️

ViewModel может иметь логику представления, основанную на; разрешения текущего пользователя, тип отображения, данные в DTO и т. д.

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

Answer 6

Оба служат одной и той же цели для моделирования данных, входящих и исходящих из серверной части.

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

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

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