Какова наилучшая практика, модели Entity Framework или модели MVC?

Что лучше всего использовать при вызове данных базы данных при использовании Entity Framework с Code-First?

Я впервые использую Entity Framework с MVC и заметил, что он автоматически создает модели в моем DataLayer. У меня также есть базовые модели в моем пользовательском интерфейсе MVC, которые позволяют мне манипулировать и отображать данные в моих представлениях. В настоящее время я собираю данные, используя свой слой рабочего процесса, а затем автоматически сопоставляю модель базы данных с моей моделью пользовательского интерфейса для отображения данных.

Это лучшая практика? Должен ли я использовать модели Entity Framework вместо моих моделей пользовательского интерфейса? Или это вообще возможно сделать наповал?

Будем признательны за любую информацию по этому вопросу.


entity-framework asp.net-mvc data-layer
person Lando    schedule 12.03.2013    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Предполагается, что POCO, созданные EF, будут использоваться в качестве вашей модели. Общая идея заключается в том, что у вас есть EF, обеспечивающий доступ к вашей базе данных. Вы запрашиваете EF, используя LINQ и/или методы расширения, и в итоге получаете объект или набор объектов, которые вы отображаете в своем пользовательском интерфейсе, связывая их в WPF. Это, конечно, если вы используете WPF, а не старые WinForms. Я могу сказать вам по опыту, что это очень простой процесс, когда вы знакомитесь с технологиями. Вот как будет работать очень простая установка.

Более продвинутый способ сделать это — добавить в смесь такие архитектуры, как Model-View-ViewModel (MVVM) и, возможно, шаблон репозитория, после чего вы получите лучшее разделение кода и представления за счет повышенной сложности.

Я не знаю, какой вариант MVC вы используете и как его можно смешать с вышеперечисленным, но если вы хотите узнать больше о том, как должен работать EF, вам следует изучить технологии, которые я перечислил выше. .

person Manos Dilaverakis    schedule 12.03.2013
comment
MVVM Похоже, это лучший вариант, поскольку у меня уже есть готовый шаблон репозитория, который использовался при использовании Linq-To-SQL. Я модифицировал свой универсальный репозиторий для работы с сущностями, и мне нужно будет выполнить приличное количество манипуляций с данными на стороне пользовательского интерфейса. - person Lando; 12.03.2013

arrow_upward
4
arrow_downward

Это зависит от вас на самом деле. Если вы хотите повторно использовать одни и те же объекты EF для своих моделей представлений; вперед, продолжать. Лично я предпочитаю этого не делать. Это связано с тем, что обычно вы добавляете в класс кучу свойств, которые не имеют ничего общего с тем, что хранится в данных, и да; Я знаю, что вы можете использовать атрибут NotMapped следующим образом:

[NotMapped]
public string MyExtraProperty { get; set; }

но я предпочитаю этого не делать. Кроме того, вы в конечном итоге добавляете [Display] и другие атрибуты к своим свойствам, и, прежде чем вы это узнаете, у вас есть что-то, украшенное как атрибутами, специфичными для данных, так и атрибутами, специфичными для пользовательского интерфейса, и это может запутаться, если вы не будете осторожны.

Так что для меня; У меня есть следующее:

  1. Доменная сущность
  2. Посмотреть модель
  3. Сервис/Фасад/Репозиторий

Контроллер вызывает репозиторий для получения объекта домена и преобразует его в модель представления для отображения.

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

person Matt    schedule 14.03.2013