(MVC / MVVM). В чем причина создания отдельной модели представления для каждого представления? [Дубликат]

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

• Важно выполнить всю обработку в действии контроллера. Однако в примере, который вы указали, метод Repository.Get может возвращать lazily-оцененный объект IQueryable, что означало бы, что БД не пострадает, пока не будет оценен вид. По целому ряду причин это плохо. (Обходной путь состоит в том, чтобы вызвать .ToList, пока он все еще находится в контроллере).
• «В представлении не должно быть никакой нерепрезентативной логики» и «Вы не должны доверять представлению» (поскольку представление может быть предоставленный пользователем). Предоставляя объект Model (потенциально все еще подключенный к активному DatabaseContext), представление может вносить вредоносные изменения в вашу базу данных.
• Данные, отображаемые в представлении View, не всегда отображают 1: 1 с данными модели, например, рассмотрим страницу «Сведения о пользователе»: объект «Модель пользователя EF» представляет свою сущность в базе данных, поэтому он, вероятно, выглядит следующим образом: User { UserId, UserName, PasswordHash, PasswordSalt, EmailAddress, CreatedDate }, тогда как поля на странице «Сведения о пользователе» будут User { UserId, UserName, Password, ConfirmYourPassword, EmailAddress }, do вы видите разницу? Ergo, вы не можете использовать модель пользователя EF в качестве модели представления, вы должны использовать отдельный класс.
• Опасности манипуляции с моделью: если вы разрешите ASP.NET MVC ( или любая другая инфраструктура) связывают модель с входящим HTTP POST-запросом (принимая приведенный выше пример сведений о пользователе), пользователь может сбросить пароль пользователя, присвоив значение свойства UserId. ASP.NET будет переписывать это значение во время привязки и, если вы специально не дезинформируете его (что будет так же тяжело, как создание отдельных ViewModels), тогда эта уязвимость останется.
• В проектах с несколькими разработчиками, работающими в команде ситуация, , важно, чтобы все было согласовано . Не обязательно, чтобы на некоторых страницах использовались специальные модели ViewModels, но на других страницах, использующих модели EF, потому что команда не разделяет сознательный разум, все должно быть документировано и, как правило, имеет смысл. По той же причине один разработчик может уйти, не помещая чрезмерную документацию XML в свой исходный код, но в командной ситуации вы развалитесь, если вы этого не сделаете.

небольшое обходное решение в вашем случае Я поделюсь с вами, но учтите предварительные условия:

• Ваши взгляды могут быть полностью доверены
• Ваши взгляды содержат только презентационную логику
• Ваше приложение в основном CRUD
• Ваши представления соответствуют 1: 1 с каждой моделью сущности EF (т. е. нет JOIN)
• . Ваши взгляды касаются только простых простых моделей для форм POST , а не сложные модели (т. е. объектный граф)

... тогда вы можете сделать это:

• Поместить все односторонние, связанных с данными в вашу коллекцию ViewData, или ViewBag в MVC 4 (или даже общий ViewData<T>, если вы хардкор). Это полезно для хранения заголовков HTML-страниц и обмена данными с мастер-страницами.
• Используйте ваши полностью оцененные и загруженные EF-модели в качестве моделей View<TModel>.

Но используйте этот подход с осторожностью, потому что он может ввести несогласованность.