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

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

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

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

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

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

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

На моделях просмотра вы должны проверить все, что характерно для приложения, например, например, дата должна быть в культуре формата в США, ….

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

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

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

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

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

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

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

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

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

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

Причина три: Свободная муфта

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

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

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

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

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

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

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

Давайте будем гением компьютера.