Возможный дубликат:
ASP.NET MVC - модель Linq to Entities как ViewModel - это хорошая практика?
Можно ли использовать классы объектов EF в качестве моделей представления в ASP.NET MVC?
Что делать, если viewmodel на 90% совпадает с классом сущности EF?
Скажем, у меня есть класс Survey в модели Entity Framework. Это 90% соответствует данным, требуемым для просмотра, чтобы отредактировать его. Единственное отличие от модели представления - это одно или несколько свойств, которые будут использоваться в нем (которые должны заполнять объект Survey, потому что класс EF не может быть непосредственно сопоставлен с тем, как его свойства представлены (под-флажки, группы радио и т.д.)..))
Передаете ли вы их с помощью ViewData []? Или создать копию класса Survey (SurveyViewModel) с новыми дополнительными свойствами (он должен иметь возможность копировать данные из опроса и обратно к нему)?
Edit: Я также пытаюсь избежать использования Survey в качестве свойства SurveyViewModel. Это будет выглядеть странно, если некоторые свойства Survey обновляются с помощью UpdateModel или с помощью связующего по умолчанию, а другие (которые нельзя напрямую сопоставить с сущностью) - используя пользовательские свойства SurveViewModel в контроллере.
Мне нравится использовать подход Джимми Богарда всегда с отношением 1:1 между представлением и моделью представления. Другими словами, я не буду использовать модели своего домена (в данном случае ваши объекты EF) в качестве моделей представлений. Если вы чувствуете, что делаете много работы между ними, вы можете использовать что-то вроде AutoMapper, чтобы выполнить эту работу для вас.
Некоторым людям не нравится проходить эти классы моделей до самого представления, тем более что это классы, привязанные к конкретной ORM, которую вы сейчас используете. Это означает, что вы сильно привязываете свою инфраструктуру данных к своим типам просмотров.
Однако я сделал это в нескольких простых приложениях MVC, используя тип сущности EF в качестве модели для некоторых сильно типизированных представлений - он отлично работает и очень прост. Иногда просто выигрывает, иначе вы можете приложить много усилий и кода для копирования значений между почти идентичными типами моделей в приложении, где реально вы никогда не удаляетесь от EF.
У вас всегда должны быть модели просмотра, даже если они 1:1. Есть практические причины, а не связь между слоями базы данных, на которые я сосредоточусь.
Проблема с областью, сущностью framework, nhibernate или linq 2 sql-моделями в качестве классов просмотра заключается в том, что вы не можете справиться с контекстной валидацией. Например, заданный класс пользователя:
Когда человек регистрируется на вашем сайте, он получает экран пользователя, тогда вы:
Когда администратор редактирует имя пользователя, он получает экран пользователя, а затем:
Теперь выведите контекстуальную проверку с помощью FluentValidation, атрибутов DataAnnotations или даже настраиваемых методов IsValid() в бизнес-классах и проверьте только изменения имени и электронной почты. Вы не можете. Вы должны представлять различные контексты как разные модели представления, потому что проверка на этих моделях изменяется в зависимости от представления экрана.
Ранее в MVC 1 вы могли обойти это, просто не размещая поля, которые вы не хотели бы утверждать. В MVC 2 это изменилось, и теперь каждая часть модели получает подтверждение, отправляется или нет.
В больших проектах я обычно разделяю бизнес-объекты из объектов данных как вопрос стиля. Это намного проще, если программа и база данных изменяются и влияют только на уровень управления (или виртуальной машины).