Entity Framework & Class Models в MVC

Question

Я новичок в разработке приложений MVC и по большей части наслаждаюсь. Одна вещь, которая меня немного смущает, - это использование Entity Framework. EF обычно (по крайней мере, по моему опыту) определяет несколько таблиц и отношений через таблицу .edmx. Пара вопросов:

• Зачем мне определять отдельный файл классов для конкретной таблицы, если EF создает все классы, которые мне нужны, в фоновом режиме?

• Из некоторых подходов к валидации, которые я видел, они хотят определить логику валидации в классе, связанном с моделью для таблицы. Если я использую EF, у меня будет файл .cs, описывающий модель, и файл .edmx, описывающий ту же таблицу (в дополнение к связанным таблицам)?

• Если да, как вы соединяете файл .cs с определением .edmx, чтобы CRUD легко передавался из EF?

Извините, если это кажется легким вопросом, но я просто пытаюсь обернуть голову вокруг этих фундаментальных понятий. Слишком много примеров используют только одну таблицу, где в моем бизнесе я НИКОГДА не пишу приложение, которое использует одну таблицу. Всегда есть несколько таблиц по отношению друг к другу с внешними ключами. Спасибо за ваши быстрые ответы.

Answer 1

Для учебника, который показывает использование частичных классов - в приложении Web Forms, но для MVC будет использоваться та же методика - см. Добавление метаданных к модели данных в этом учебнике:

http://www.asp.net/web-forms/tutorials/getting-started-with-ef/the-entity-framework-and-aspnet-getting-started-part-8

Из вашего комментария "EF обычно (по крайней мере, по моему опыту) определяет несколько таблиц и отношений через таблицу .edmx." Похоже, вы знакомы только с Database First и Model First - для ознакомления с Code First и объяснения различий, а затем для серии руководств с примером MVC с использованием Code First, см. это руководство:

http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/creating-an-entity-framework-data-model-for-an-asp-net-mvc-application

Answer 2

Хорошие вопросы, Дэррил.Вот мои ответы на ваши пункты:

• Определение отдельных классов моделей, соответствующих моделям данных, которые создает EF, - это, как правило, хорошая идея для простого разделения вашего "доступа к данным".от ваших бизнес-моделей объектов, которые будут использоваться во всем приложении.Некоторым людям не нравится этот подход, потому что он создает некоторые накладные расходы, когда речь идет о сопоставлении ваших сущностей с POCO, но, если вы используете такой инструмент, как AutoMapper, накладные расходы минимальны.Преимущество заключается в том, что вы создаете слой разделения между вами и вашей (вероятной) развивающейся моделью данных.

• Вы можете определить логику валидации в классе собеседника (просто в частичном классе, который находится рядом).- со своей сущностью), но это будет означать, что вы будете использовать эту сущность в своем приложении, а некоторые будут спорить, что это не лучшая идея.Альтернативный метод, как упомянуто выше, заключается в создании ваших собственных POCO для отражения сущностей, которые создает EF, и размещении ваших атрибутов проверки в POCO.

• Я упоминал об этом в предыдущем пункте, носпособ сделать это - определить классы друзей.Дайте классы EF buddy Google, и вы должны найти множество примеров того, как это сделать.

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

Я надеюсь, что это поможет ...