EF 4 с POCO в библиотеке классов как модель MVC 2 - PullRequest
1 голос
/ 13 августа 2010

Я изучаю Entity Framework 4 с POCO в качестве моей Модели для веб-приложения MVC2.Причина, по которой мне понадобится модель и код доступа к данным в отдельной библиотеке, заключается в том, что я могу поделиться им с другим веб-приложением, которое служит для доступа наших клиентов к порталу.

У меня вопрос,Я теряю какие-либо типичные функции модели MVC2, имея код EF4 и POCO в другом проекте?Или, может быть, еще один способ задать вопрос: сможет ли среда MVC работать со слоем Model точно так же, если он находится в отдельном проекте, а не в папке Models?

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

1 Ответ

5 голосов
/ 13 августа 2010

Односборочные проекты только для небольших проектов

Мне никогда не нравилась папка "Модели". Я скорее помещаю отдельные слои / ярусы в отдельные сборки. Шаблон проекта MVC просто создает многоуровневое приложение в одной сборке.

Я предпочитаю решения, сделанные из нескольких проектов:

  • Web - интерфейсное веб-приложение, т.е. Asp.net MVC (ссылки Сервисы и Объекты )
  • Службы - сборка бизнес-уровня (ссылки Данные и Объекты )
  • Объекты - классы POCO, интерфейсы и т. Д., Которые являются общими для всех (не относится ни к какому другому проекту решения)
  • Данные - Фактическая модель EF и расширения, репозитории и т. Д. (Ссылки Объекты )

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

Так в прошлом проекте: модель EF была в проекте Data (а также в репозиториях и т. Д.), А POCO - в объектах. Все взаимодействие между проектами осуществлялось с помощью классов из проекта Objects.

Итак Веб используется Сервис ,
которые в свою очередь использовали репозитории (в Data ),
который в свою очередь вызвал EF для манипулирования данными.
Все данные, передаваемые туда и обратно, используют POCO в Objects .

Таким образом, репозитории должны были преобразовывать сущности в фактические POCO (они не были 1: 1) при возврате данных и создании сущностей при выполнении операций записи. И это преобразование было выполнено с помощью методов расширения для сущностей, поэтому преобразование всегда выполнялось в одном методе, что облегчало его поддержку, когда мы либо меняли сущность, либо класс POCO. Нам не нужно было сканировать весь код для всех преобразований, мы просто настроили наш метод расширения ToPoco() (они на самом деле назывались так).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...