Почему я должен использовать модели просмотра?

Question

Я новичок в разработке веб-приложений с использованием ASP.NET MVC.На самом деле, я довольно новичок в разработке веб-приложений, независимо от технологии.

В настоящее время я работаю над проектом, чтобы лучше узнать среду ASP.NET MVC.При чтении в SO и в других местах в Интернете, кажется, что консенсус заключается в том, что представления никогда не должны иметь непосредственного отношения к бизнес-объектам (то есть объектам, реализующим бизнес-логику и содержащим связанные атрибуты).Вместо этого следует использовать модели просмотра.Однако это приводит к возникновению нескольких проблем:

• Куда я могу поместить свой код проверки?
• Мне нужно добавить код для сопоставления между бизнес-объектами и моделями представления.

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

Просто разъяснение ;Я не ищу примеры того, как справиться с этими двумя проблемами с моделями представлений выше, а просто объясняю, почему мне вообще следует использовать модели представлений.

Answer 1

Где я могу поставить свой проверочный код?

На моделях представления вы должны проверить все, что специфично для приложения, например, дата должна быть в культуре формата en-US, ....

Мне нужно добавить код для сопоставления бизнес-объектов и моделей просмотра.

Вот почему существуют такие инструменты, как AutoMapper .

Различные проблемы возникают при непосредственном использовании моделей вашего домена в представлениях:

• Представления предъявляют особые требования к отображению данных (локализация / глобализация), поэтому вы либо в конечном итоге получаете код спагетти в своих представлениях, либо помещаете этот код в свои модели, чтобы они стали менее пригодными для повторного использования в других приложениях, поскольку вы их загрязнили с конкретными презентационными материалами
• У вас есть разные требования к проверке, основанные на представлении. Давайте возьмем для примера случай добавления и обновления представлений. В представлении «Добавить» свойство Id не понадобится и не потребуется, поскольку вы будете вставлять новый элемент. В представлении «Обновление» потребуется свойство Id, поскольку вы будете обновлять существующий элемент. Было бы трудно обработать эти конкретные правила проверки без моделей представления.

• Модели могут содержать такие свойства, как IsAdmin, и тогда я оставляю на ваше воображение значение действия контроллера со следующей сигнатурой:

  [HttpPost]
  public ActionResult CreateUser(BusinessObjectUser user) { ... } 
  

  при условии, что вы скрыли это свойство из базовой формы, не включив его.

• Бизнес-модели меняются не часто, тогда как пользовательский интерфейс может меняться чаще. Что если ваш клиент попросит вас разделить экран на две части? Изменяется способ представления информации и форматирования. Если вы используете свои модели непосредственно в представлениях, спагеттичность ваших представлений становится все хуже и хуже с каждым изменением.
• Около 60% вопросов, на которые я отвечаю на StackOverflow в теге asp.net-mvc, не задавалось бы, если бы ОП использовал модель представления.

Answer 2

Три причины, по которым вам следует использовать модели просмотра:

Причина 1: удаление логики из ваших представлений

Причина два: безопасность

Причина три: слабая связь

Ниже ссылка может пригодиться: http://www.codeproject.com/Articles/223547/Three-reasons-to-why-you-should-use-view-models

Answer 3

Прежде всего, предоставление представлениям прямого доступа к бизнес-объектам в ASP.NET MVC создает некоторые дополнительные проблемы безопасности. ASP.NET MVC выполняет связывание моделей для вас, когда пользователь отправляет значение обратно на ваш контроллер. Это может открыть вас для различных видов атак. Вводя модель представления между ними, вы можете быть уверены, что связаны только те поля, которые вам интересны (поскольку ViewModel будет содержать только те поля, которые вас интересуют).

Что касается других вопросов:

Где я могу поставить свой код подтверждения?

Я непосредственно использую DataAnnotations в моих моделях ViewModel. Это позволяет мне использовать архитектуру проверки модели, встроенную в ASP.NET MVC. Если есть какая-либо проверка за этим, я обрабатываю это в моем контроллере.

Мне нужно добавить код для сопоставления бизнес-объекты и просмотр моделей.

True. Но использование чего-то вроде AutoMapper может значительно сократить объем стандартного кода, который вы должны писать вручную.

Answer 4

MVC легко понять и имеет очень мало накладных расходов. Но те, кто какое-то время использовал шаблон Model-View-Controller, знают, что он не идеален. Даже не близко. Шаблон Model-View-ViewModel предлагает интересную альтернативу.

Важно понимать, что шаблон Model-View-ViewModel расширяет шаблон Model-View-Controller. Это не драматическая смена парадигмы, если вы привыкли к MVC. Хотя преимущества MVVM невелики, они глубоки.

Какие преимущества у MVVM перед MVC?

1. Лучшее разделение интересов
2. Улучшенная тестируемость
3. Прозрачная Связь