ViewModels с asp.net mvc 4 и EntityFramework в чем суть

Я могу вспомнить пару случаев, когда отдельный уровень классов модели представления - хороший способ пойти, и я попытаюсь объяснить их с точки зрения общего инструмента ORM и общей инфраструктуры MVC - обратите внимание, что ни один из этих двух случаи специфичны для ASP.NET MVC Framework с Entity Framework (и даже для программирования в .NET ...).

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

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

Это несколько пуристическая цель - в настоящем приложении MVC уровень представления имеет доступ только к данным, которые ему нужны в данный момент, и ни к чему другому. Теперь объект модели представления становится спецификацией от уровня представления к контроллеру: Это данные, которые мне нужны для отображения запрошенного представления. Чтобы придерживаться фундаментального MVC принципы, вы хотите убедиться, что все решения о том, какие данные отображать, принимаются контроллером.

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

Причина 2: Избегайте проблем с отслеживающими способностями вашего ORM-инструмента.

Некоторые инструменты ORM - даже те, которые возвращают обычные объекты ¹ - используют довольно сложные методы для отслеживания изменений в объектах, которые вы получаете из уровня данных, чтобы упростить изменение записей. Например, вы можете получить объект из своего хранилища данных, изменить некоторые свойства в этом экземпляре, а затем вызвать метод save() в другом месте, и объект будет обновлен в базе данных. В зависимости от инструмента ORM перенаправление ваших ORM-сущностей на уровень представления может иметь любой диапазон последствий, от проблем с производительностью (худший случай: соединения с базой данных остаются открытыми) до нежелательных эффектов (например, ошибка на уровне представления изменяет свойства в хранилище данных). Чтобы избежать этого, повторно сопоставьте свои сущности с настоящими обычными объектами, которые не имеют отношения к вашему инструменту ORM, прежде чем отправлять их слишком далеко вниз по конвейеру приложения. Просмотр моделей - это один из многих способов достижения этой цели.

Обратите внимание, что то, нужно это или нет, полностью зависит от вашего инструмента ORM. Я недостаточно хорошо знаю внутреннюю работу Entity Framework, чтобы знать, нужно ли вам заботиться, но в (очень) ранних воплощениях EF это было проблемой, по крайней мере, когда не использовался подход Code-First.

Выводы: нужно ли вам заботиться?

Нет, не обязательно. Вы могли бы прекрасно обойтись без моделей представления, и в этом случае они просто еще один уровень абстракции, который на самом деле не добавляет ничего, кроме сложности вашему приложению. Все сводится к тому, предъявляет ли ваш ORM-инструмент какие-либо требования к вашему коду, и являетесь ли вы сторонником MVC.

Примечание: а как насчет уязвимостей массового назначения?

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

Для меня модель представления - это объект передачи данных от контроллера к представлению, помогающий контроллеру отсортировать и суммировать данные, которые должны быть отображены < / em>. Чтобы избежать таких проблем, как уязвимости массового назначения, я обычно использую модели редактирования, которые очень похожи на модели просмотра, но в другом направлении, то есть для контроллера . Не все делают это различие - и меня не очень волнует, будете вы это делать или нет. Но, используя этот словарь, я бы рекомендовал всегда использовать модели edit, когда вы позволяете пользователям изменять ваши данные, и использовать модели view только тогда, когда это помогает. ты.