Как спроектировать MVC 3, EF, ViewModels, AutoMapper, POCO, репозиторий и единицы работы в n-уровневом проекте? - PullRequest
Новая
       52

Как спроектировать MVC 3, EF, ViewModels, AutoMapper, POCO, репозиторий и единицы работы в n-уровневом проекте?

7 голосов
/ 08 ноября 2011

Я читал бесчисленные статьи о том, как сконструировать новое приложение MVC 3, используя лучшие практики.

90% статей объединяют файлы EF EDMX в тот же проект, что и приложение MVC. Те, кто разделяют эти элементы в свои собственные проекты, не уточняют, в какой проект входит каждый и какие ссылки имеет каждый проект. Обычно они состоят из фрагментов кода, которые отлично подходят для обучения выполнению определенной функции, но не говорят мне, как разрабатывать решение.

Я считаю, что мне нужно как минимум 5 проектов в моем решении. Может кто-нибудь сказать мне, если у меня есть правильный макет здесь?

  • Уровень доступа к данным - Содержит файлы EF EDMX. (Возможно, автоматически сгенерированный код DBContext?)
  • Бизнес-уровень - Содержит классы IRepository и Repository, классы UoW, а также бизнес-логику для домена. - Содержит ссылку на DAL.
  • ViewModels - Содержит модели представления, которые будут использовать AutoMapper для перехода между моим DAL и уровнем представления. - Содержит ссылку на DAL.
  • Приложение MVC 3 - Стандартное приложение MVC 3. Содержит ссылки на проекты BusinessLayer и ViewModels.
  • Тест - Модульное тестирование.

Это выглядит правильно? Может кто-нибудь указать мне хорошую статью, которая использует n-уровневую разработку с ViewModels, AutoMapper, шаблонами репозитория и EF4?

Ответы [ 3 ]

6 голосов
/ 08 ноября 2011

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

Бизнес-уровень

  • Домен / Бизнес-модель и услуги
  • Уровень доступа к данным

Приложение MVC

  • Просмотр моделей
  • Automapper
  • Контроллеры
  • Просмотры

Тесты

  • Юнит-тесты
3 голосов
/ 08 ноября 2011

Мне нравится следующее

Домен - содержит модели и ViewModels

Услуги - бизнес-логика и представление модели гидратирующего (т. Е. Населения) кода

Контракты или интерфейсы - интерфейсы репозитория, единица работы, IContext и ICache Веб-сайт DataAccess - конкретная реализация структуры сущности

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

кстати, посмотрите хороший атрибут Джимми здесь: http://lostechies.com/jimmybogard/2009/06/30/how-we-do-mvc-view-models/

То, что вы обрисовали в общих чертах выше, также хорошо. Это очень субъективный вопрос. Мои общие рекомендации таковы: «Если кто-то может открыть проект и иметь представление о том, где что-то искать, вы, вероятно, делаете это правильно»

1 голос
/ 08 ноября 2011

Как я обычно это делаю:

  1. Проект модели - содержит модель, сгенерированную из БД и контекста.
  2. Проект POCOs - Содержит бизнес-объекты
  3. Контроллер проекта - аналогично вашему репозиторию
  4. Проект MVC3 - внешний интерфейс, ВКЛЮЧАЯ модели представлений и классы репозитория, которые включают в себя автоматические эквиваленты.
  5. Юнит-тесты

Архитектуразависит от технологии, используете ли вы EF, Hibernate, MVC, веб-формы и т. д. И вы обычно комбинируете шаблоны.Кроме того, это в основном зависит от каждого конкретного проекта.

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

...