2013-03-28 4 views
8

Я пытаюсь понять все отношения MVC/EF. Если я создаю модель сущности, которая будет взаимодействовать только с базой данных (так как вы не должны передавать модель сущности в представление), то класс для модели и, наконец, модель представления, показанная ниже. Мой единственный вопрос заключается в том, что кажется излишним иметь второй класс, единственный в примерах, которые я видел, заключается в том, что они применяют аннотации данных к этому классу, поскольку он взаимодействует с представлением. Почему так важно убедиться, что объекты объектов arent не отображаются на уровне представления?Entity Framework и отношения с MVC

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

Entity Model:

public class Product 
{ 
    [Key()] 
    public int ID { get; set; } 
    public string Name { get; set; } 
    public string Description { get; set; } 
    public double Price { get; set; } 
} 

Модель:

public class ProductModel 
{ 
    public int ID { get; set; } 
    [StringLength(50)] 
    [Required(ErrorMessage = "Product Name is required.")] 
    [Display(Name = "Product Name")] 
    public string Name { get; set; } 
    public string Description { get; set; } 
    public double Price { get; set; } 
} 

ViewModel:

public class ProductViewModel 
{ 
    Product myProduct { get; set; }\ 
    //Plus any other properties I may need for the view. 
} 

UPDATE:

В Например, я читал, что у них также есть набор DBContext следующим образом. Тогда класс ProductModel бесполезен?

public class MyAppContext : DbContext 
{ 
    public MyAppContext() 
     : base("name=DBConnection") 
    { 
    } 

    public DbSet<Product> Products { get; set; } 

} 
+1

Где вы читали, что вы не должны проходить «модель лица» с точки зрения? – Floremin

ответ

1

Есть две основные причины, по которым я создаю класс модели, отдельно от моего объекта.

  1. Как вы упомянули, атрибуты. Возможно, вы захотите повторно использовать свои объекты в нескольких приложениях, и они могут не использовать одни и те же атрибуты. Вы не хотите загрязнять свои сущности этими данными.

  2. В зависимости от них ORM, вашим объектам может потребоваться базовый класс. Или могут быть атрибуты или другие настройки, которые вы должны применить к объектам. Это может вызвать трудности при тестировании вашей бизнес-логики. Кроме того, если вы измените ORM или что-то в своих изменениях ORM, вы сохраните это изменение отдельно от остальной части приложения.

В принципе, вы изолируете различные слои вашего приложения и защищаете один слой от изменений, внесенных в другой.

+0

Спасибо! Итак, с помощью DBContext, действительно ли все остальные слои полезны? Или это делается? – user2220986

+0

Это, вероятно, ничего не повредит, если у вас не будет дополнительных слоев, но я думаю, что это хорошая идея. – cadrell0

+0

Кажется, я мог избавиться от класса ProductModel и просто создать эти свойства в модели viewmodel, но, я думаю, это зависит от того, будет ли я повторно использовать этот класс продукта в нескольких других моделях представлений или нет. – user2220986

1

Необходимо Product class, ProductViewModel class, а затем ваш DbContext. Если вы делаете это в первый раз, прочитайте Pro ASP.NET MVC 3 Framework, Third Edition

или

Pro Asp.Net Mvc 4

Они имеют подробную информацию о MVC, и обе книги имеют Real Application tutorial you can follow от начала до конца, включая развертывание.

Вы также узнаете о модульном тестировании и других инструментах, таких как MVC Dependency Injection (Ninject) и Moq

+3

Или прочитайте http://www.asp.net/mvc бесплатно. – jrummell

-1

Почему это так важно, чтобы убедиться, что объекты сущности Арента экспонировались на виде слой?

Это не так. Для простого контроллера CRUD часто проще просто передать объект объекта. Для более сложной страницы вы можете одновременно взаимодействовать с более чем одним объектом/типом Entity. Как вы передадите информацию обо всех объектах без создания нового класса модели?

1

В дополнение к ответам выше, еще один пункт, о котором не упоминалось, чтобы предотвратить отправку данных в view/client, который не должен быть.

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

иногда вы можете получить класс DBcontext, класс/модель EF/базы данных и несколько моделей, каждый из которых содержит разные подмножества данных из модели базы данных.

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

3

Есть моменты, особенно на простых моделях, где может не потребоваться модель представления. Но, и большое «но», я нашел очень мало примеров этой ситуации, и даже тогда, я позже, как правило, считаю необходимым вернуться и создать модель представления, так или иначе. Наличие специализированной модели просмотра более безопасно, проще и проще во всём.

Вы можете посмотреть на него как на дополнительную работу, но подумайте об этом с точки зрения разделения проблем (что является целым рядом с MVC). Если я хочу представить SelectList для ввода, например, я могу либо добавить его в ViewBag, либо в мою модель. Если я добавлю его в ViewBag, я потеряю сильную типизацию, которая никогда не будет идеальной, но она также не принадлежит к моей базе данных. Имея модель просмотра, позвольте мне поместить эту информацию точно, куда она должна идти: сильно типизированная модель, которая существует для обслуживания представления и только для обслуживания представления.

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

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

0

Чтобы начать, есть что-то недостающее и комбинированные техники, одно - абстрагироваться полностью DAL от всего другого слоя, это техника. Но есть и другая техника, которая может быть использована; используйте классы «Сущности» в качестве классов домена. По простому сценарию мы всегда используем классы домена на уровне бизнес-класса для применения всех правил бизнеса. это поможет нам многому объединить тестируемые сквозные слои и избегать неиспользуемых связей между слоями без увеличения количества строк кода/количества классов.

Кроме того, этот подход, чтобы этот домен объекты (классы домена) Повсеместно все слои сделают вам вещи намного проще, когда вы работаете с MVC, так как этот класс может иметь аннотации данных, которые будут использоваться:

  1. Просмотров за валидаций
  2. базы данных для целостности

Кроме того, чтобы понять концепцию и использование этого типа классов есть что-то, что нам нужно обратить внимание. Если мы используем POCO как наши сущности и классы домена, эти же классы не являются теми же классами, которые Entity Framework будет использовать при интерпретации запросов к БД. Вместо этого EF создаст динамические классы (полученные из POCO), которые представляют этот объект домена как объект и загружают все виртуальные поля, как правило, связанные объекты.

И вы будете сохранять код классов и тривиальное переназначение.

Надеется, что это помогает

1

ViewModel будет то, что на самом деле получает передается в/из браузера, часто через JSON, если вы создаете что-то, что можно обновлять на месте/сохранить на месте. Итак:

  • ASP.Net MVC имеет некоторые ограничения, вокруг того, что он может производить/потреблять более JSON (и его ограничения, немного отличаются в каждом направлении); вы можете использовать ViewModel для того, чтобы обойти это.

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

  • Некоторые естественные структуры в JSON на самом деле недоступны в базе данных - например, у вас может быть эквивалент словаря, хранящегося в вашей модели, например, одна таблица с некоторыми значениями и другая таблица с указателем FK к нему, ИД и строковое значение - но для того, чтобы браузер мог использовать его, вам может понадобиться только это строковое значение. Итак, в ViewModel вы представляете, что все с простым Словарем (который заканчивается как простой объект JS на клиенте).

  • Часто такие вещи, как форматирование даты, являются слабыми на клиенте или надуманными, в зависимости от клиента, имеющего точные системные часы и т. Д. Я часто использую String в моей модели ViewModel, где у меня есть DateTime в моей модели и переводится с UTC к их часовому поясу и хорошо отформатировать его на сервере, прежде чем он появится в своем браузере.

  • Иногда вам нужно избегать подвергать детали модели браузерам; например, в некоторых системах, если вы выставили идентификатор строки в браузере, вы можете создать угрозу безопасности. ViewModel делает тривиальным скрывать части вашей модели.

Смотрите также: how to design ViewModel