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

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

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

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

Любая информация по этому вопросу будет оценена.

Источник

2 ответа

Решение

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

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

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

Источник

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

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

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

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

  1. Домен Сущность
  2. Посмотреть модель
  3. Услуги / Фасад /Repository

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

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

Источник
Другие вопросы по тегам