ASP.NET MVC: использование сущностей EF в качестве моделей просмотра?

Возможный дубликат:
ASP.NET MVC - модель Linq to Entities в качестве модели представления - это хорошая практика?

Можно ли использовать классы сущностей EF в качестве моделей представления в ASP.NET MVC?

Что, если модель просмотра на 90% совпадает с классом сущности EF?

Допустим, у меня есть класс Survey в модели Entity Framework. Он на 90% совпадает с данными, необходимыми для редактирования. Единственное отличие от того, какая модель представления должна иметь, - это одно или несколько свойств, которые будут использоваться в ней (которые необходимы для заполнения объекта Survey, потому что класс EF не может быть напрямую сопоставлен с тем, как его свойства представлены (вспомогательные флажки, радиогруппы и т. .))

Вы их передаете с помощью ViewData []? Или создать копию класса Survey (SurveyViewModel) с новыми дополнительными свойствами (он должен иметь возможность копировать данные из Survey и обратно в него)?

Изменить: я также стараюсь избегать использования Survey в качестве свойства SurveyViewModel. Будет выглядеть странно, если некоторые свойства Survey обновляются с использованием UpdateModel или связывателя по умолчанию, а другие (которые не могут быть напрямую сопоставлены с сущностью) - с использованием настраиваемых свойств SurveViewModel в контроллере.


viewmodel asp.net-mvc
person Evgenyt    schedule 19.10.2010    source источник

Ответы (4)


arrow_upward
18
arrow_downward

Мне нравится использовать подход Джимми Богарда всегда иметь отношение 1: 1 между представлением и моделью представления. Другими словами, я бы не использовал свои модели предметной области (в данном случае ваши объекты EF) в качестве моделей представления. Если вам кажется, что вы выполняете много работы по сопоставлению между ними, вы можете использовать что-то вроде AutoMapper, чтобы сделать эту работу за вас.

person MrDustpan    schedule 19.10.2010
comment
+1 за Automapper ... только что нашел, и мне это нравится. - person Martin; 19.10.2010
comment
ValueInjecter намного лучше - person mare; 13.01.2011
comment
Automapper изменил мою жизнь, он невероятно полезен, особенно когда вы привыкнете к нему и научитесь отображать свойства навигации. - person JBeagle; 04.10.2013

arrow_upward
15
arrow_downward

Некоторым людям не нравится передавать эти классы модели полностью в представление, особенно потому, что это классы, привязанные к конкретной ORM, которую вы в настоящее время используете. Это означает, что вы жестко привязываете свою структуру данных к своим типам представлений.

Однако я сделал это в нескольких простых приложениях MVC, используя тип сущности EF в качестве модели для некоторых строго типизированных представлений - он отлично работает и очень прост. Иногда просто побеждает, иначе вы можете приложить много усилий и кода для копирования значений между почти идентичными типами моделей в приложении, где реально вы никогда не откажетесь от EF.

person Simon Steele    schedule 19.10.2010
comment
+1 это, отличный комментарий. - person jhartzell; 23.10.2014

arrow_upward
8
arrow_downward

У вас всегда должны быть модели просмотра, даже если они 1: 1. Есть практические причины, а не связывание уровней базы данных, на которых я сосредоточусь.

Проблема с доменом, структурой сущностей, моделями sql nhibernate или linq 2 в качестве классов представления заключается в том, что вы не можете хорошо справиться с контекстной проверкой. Например, учитывая класс пользователя:

Когда человек регистрируется на вашем сайте, он видит экран пользователя, в котором вы:

  1. Проверить имя
  2. Подтвердить адрес электронной почты
  3. Подтвердите, что пароль существует

Когда администратор редактирует имя пользователя, появляется экран «Пользователь», в котором вы:

  1. Проверить имя
  2. Подтвердить адрес электронной почты

Теперь предоставьте контекстную проверку с помощью атрибутов FluentValidation, DataAnnotations или даже пользовательских методов IsValid () в бизнес-классах и подтвердите только изменения имени и адреса электронной почты. Вы не можете. Вам необходимо представить разные контексты как разные модели представления, потому что проверка этих моделей меняется в зависимости от представления на экране.

Ранее в MVC 1 это можно было обойти, просто не публикуя поля, которые вы не хотели проверять. В MVC 2 это изменилось, и теперь каждая часть модели проверяется, публикуется или нет.

Роберт Харви указал еще на один хороший момент. Как ваша пользовательская Entity Framework отображает экран и проверяет двойное совпадение паролей?

person John Farrell    schedule 19.10.2010
comment
Вы делаете правильную точку зрения, но если вы выполняете сопоставления с двойным паролем, ваша модель представления на самом деле не 1: 1 с объектом модели сущности, не так ли? - person Robert Harvey; 19.10.2010
comment
@ Роберт Харви, да, я должен использовать другой пример. Подтверждение наличия пароля лучше, потому что при редактировании администратора вы никогда не меняете пароль. Спасибо, поменяю. - person John Farrell; 19.10.2010

arrow_upward
0
arrow_downward

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

person tzerb    schedule 19.10.2010
comment
Модели представления в контексте MVC относятся к классам моделей, разработанным специально для использования представлением MVC. Обычно это просто класс со свойствами, которые представляют собой подмножество вашей модели предметной области. - person Jace Rhea; 19.10.2010
comment
Спасибо за ответ. Я не использовал MVC несколько лет. Думаю, в то время это было просто руководство и несколько уроков от РС. Эта часть должна была быть объединена с MVVM. - person tzerb; 19.10.2010