Я согласен с тем, что говорит jgauffin, но я бы хотел кое-что добавить, поэтому я использую его шаблон для единообразия:
Архитектура A
1) Уровень репозитория: вызовы Entity Framework
Как очень хорошо сказал jgauffin, абстрагирование O / RM - это a хороший способ сделать тестируемый BL, на самом деле я бы сказал, что это лучший способ для модульного тестирования вашего BL , что в целом важно. Помните, однако, что есть адвокат, которые говорят, что вы не должны скрывать O / RM за репозиторием по нескольким причинам. Из этого сообщения в блоге:
Проблема с этим шаблоном заключается в том, что он полностью игнорирует существование зрелых технологий персистентности, таких как NHibernate. NHibernate уже обеспечивает иллюзию доступа к памяти, фактически, это его единственная причина существования. Декларативные запросы, проверка. OO посмотреть на персистентность магазина, проверить. Проверьте одностороннюю зависимость между доменом и хранилищем данных.
Итак, что я получу, используя шаблон хранилища, когда у меня уже есть NHibernate (или аналогичный, большинство OR / M уже имеют возможности сопоставления)?
Дебаты все еще открыты, так что это ваш звонок. С помощью NHibernate вы все еще можете тестировать BL, имитируя ISession, я не знаю, как он работает с EF: в качестве альтернативы вы можете протестировать свой BL с интеграционными тестами, работающими с базой данных в памяти (такой как SQLite).
2) Сервис / бизнес-уровень: - У каждого «менеджера» должен быть интерфейс. - У каждого «менеджера» есть 2 реализации (1 макет / 1 факт). - Методы в классах менеджера для вызова репозитория, а затем применения бизнес-логики. - Каждый метод для проверки на единицу продукции
jgauffin говорит, что вы не должны вставлять насмешки в свой BL, и он прав, но пока ваши насмешки находятся в дополнительном проекте, я вижу только преимущества во время интеграционного тестирования, особенно если вы используете сервисы WCF: тогда вы могли бы иметь разные конфигурации (или вообще не иметь конфигурации с обнаружением, только области) для макетных и реальных сервисов и тестировать свои сервисы на нескольких конфигурациях.
3) Уровень представления (MVC): - Менеджеры, которые будут созданы с помощью какого-либо шаблона Service Locator - Каждый контроллер должен иметь написанные для него модульные тесты
Есть люди, утверждающие, что Service Locator является антипаттерном , и аргумент довольно убедителен, даже если иногда оды Service Locator выглядят как меньшее зло. MVC предлагает более элегантные решения для Dependency Injection по сравнению с WebForms, поэтому вам обязательно стоит взглянуть на это.
Архитектура B
1) Сервисный / бизнес-уровень: - Содержит только конкретные классы «Менеджер» - Методы напрямую вызывают среду Entity (например, мы рассматриваем EF как репозиторий) - Интерфейсы могут использоваться, но только там, где есть необходимость в различных реализациях - Юнит тесты как и когда требуется
Как уже говорилось ранее, теоретически это может легко работать с интеграционными тестами с использованием базы данных в памяти, если она достаточно быстра для вас.
2) Уровень представления (MVC): - классы диспетчера, которые должны быть созданы напрямую - модульное тестирование только хрупкого или значительного кода кода
Единственное преимущество, которое я вижу, когда я не использую Контейнер IoC, состоит в том, чтобы иметь одну менее подвижную часть; хотя для целей тестирования я все еще использовал бы DI, так что вы действительно хотите ввести свои зависимости вручную, в стиле DI для бедного человека, для проекта среднего размера?
Резюме
Короче говоря, всегда есть середина, и мы не можем принять это решение за вас. Будучи проектом среднего размера, я бы склонялся к чему-то похожему на архитектуру А; единственное исключение - если это был недолговечный проект, где у вас есть определенная дата, когда ваше приложение устарело и будет закрыто (представьте приложение для определенного неповторяющегося события).
Вообще говоря, если это не демонстрационный проект, я редко пропускаю хорошую абстракцию.Как неявно сказал jgauffin, считают абстракции не средством обмена реализациями, а способом управления сложностью вашего приложения .