Почему два класса, модель представления и модель предметной области?

Question

Я знаю, что было бы плохо использовать доменные модели в качестве моделей представления. Если в моей доменной модели есть свойство с именем IsAdmin, и у меня есть действие Создать контроллер для создания пользователей, кто-то может изменить мою форму и получить в POST значение формы IsAdmin = true, даже если я не отображал такое текстовое поле в своем представлении , Если я использую привязку модели, тогда, когда я зафиксировал свою модель домена, этот человек теперь будет администратором. Таким образом, решение раскрывает только те свойства, которые мне нужны в модели представления, и использует инструмент, такой как AutoMapper, для сопоставления значений свойств моего возвращаемого объекта модели представления со значением моего объекта модели домена. Но я читал, что атрибут связывания в классе можно использовать для указания связывателю модели, какие свойства он должен и не должен связывать. Так в чем же причина создания двух отдельных классов (модель предметной области и модель представления), которые существенно представляют одну и ту же вещь, а затем накладывают накладные расходы при их отображении? Это скорее проблема организации кода, и если да, то как мне это выгодно?

EDIT

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

Answer 1

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

Концепция дизайна, которой я пытаюсь следовать, заключается в том, чтобы в моих представлениях было как можно меньше логики.Это означает, что в моей модели представления есть поля, такие как «CanViewThisField» или «CanEditThisField».Когда я впервые начал работать с MVC, моя модель предметной области была бы моей моделью представления, и я всегда сталкивался со сценарием, где мне требовалось всего одно или два дополнительных поля, чтобы сделать мое представление менее загроможденным.С тех пор я прошел маршрут View Model / Model Builder , и он прекрасно сработал для меня.Я больше не бьюсь над своим кодом, но могу улучшить модель представления так, как мне нужно, без влияния на модель предметной области.

Answer 2

Еще одна веская причина иметь ViewModel - это подкачка больших наборов данных. Вы можете передать представление массива Person (Person[]), но метаданные, такие как количество страниц, номер текущей страницы, размер страницы, не будут принадлежать классу Person.

Поэтому PersonListViewModel решит эту проблему.

Answer 3

ViewModel содержит только те элементы, которые требуются View.Обычно их можно рассматривать как упрощение или «уплощение» базовой модели предметной области.

Думайте о них так:

• ViewModel : этоэто данные, которые должны быть отображены в этом представлении
• Модель домена : это вся информация, которая необходима моему приложению об этом объекте для выполнения всех его функций

Например, в моем классе Заказа есть член с именем Customer, который является составной ассоциацией, то есть мой Заказ имеет Customer.В этом объекте Customer есть такие члены, как Имя, Фамилия и т. Д. Но как я могу показать это в представлении "детали" заказа или в списке заказов и клиентов, которые их разместили?

Хорошо,используя ViewModel, у меня может быть OrderListItemViewModel, который имеет член CustomerName, и я могу сопоставить комбинацию Firstname и Lastname из объекта Customer с этим.Это можно сделать вручную или, что более предпочтительно, с помощью Automapper или аналогичного.

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

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

Answer 4

вам нужно помнить, что ваши domain model classes используются только internally;то есть они никогда не отправляются клиенту.Это то, для чего используются типы моделей вашей службы (типы моделей представления) - они представляют данные, которые будут передаваться между клиентом и вашей службой.

Answer 5

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