NLayer настройки проверки работоспособности и вопросы

Question

Я настраиваю решение MVC и пытаюсь разделить его на логические проекты. Пока у меня есть следующие проекты:

• MVC (слой представления, папка Models содержит только ViewModels)
• Службы (предоставляет бизнес-логику, имеет интерфейсы и папки провайдеров)
• Репозиторий (для сохранения, имеет интерфейсы и папки провайдеров)
• Домен (POCO)

Уровень mvc ссылается на уровень сервиса, а сервис ссылается на репо. Все три ссылаются на домен, чтобы я мог передавать POCO между ними.

Имеет ли смысл такая настройка, поскольку в будущем я мог бы потенциально использовать другой уровень представления, который снова будет работать через уровень обслуживания?

На другом конце мой доменный уровень позволил бы мне менять один ORM на другой, не прерываясь? Правильно ли я считаю, что пока классы репо в слое Repo реализуют интерфейсы, я мог бы создать новый набор конкретных классов репо, которые работают с другим ORM?

Может ли мой DbContext жить в слое Repo с реализациями EF? Это где UoW будет идти?

Могут ли мои службы выполнить базовую проверку с использованием аннотаций на POCO в домене или мне следует использовать такой инструмент, как свободная проверка?

Наконец (!) Было бы правильно создать отдельный тестовый проект для каждого слоя (где это уместно)?

Заранее спасибо за помощь,

Джеймс

Answer 1

Пока вы уверены, что разрабатываете на основе интерфейса, а не реализации, это определенно будет работать.

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

Наш уровень представления использует MVP, поэтому мы можем делиться нашими докладчиками между веб-формами ASP.NET и другими внешними интерфейсами. В этом мы используем ServiceFactory, который использует внедрение зависимостей для создания наших сервисов. Это может быть клиентский прокси WCF или прямой сервис. Теперь докладчику не нужно, если вызов идет через WCF или напрямую.

В нашем слое Service мы используем UnitOfWork, который оборачивает набор репозиториев. UoW также построен через DI.

Мы используем Entity Framework и генерируем из него объекты POCO. Мы только решили не передавать POCO полностью на уровень представления / просмотра, но только на уровне бизнеса и обслуживания. Из уровня сервиса для просмотра мы используем собственные DTO. В настоящее время EF и UoW живут в одном проекте. Мы могли бы переместить их в другую сборку и загрузить их оттуда, но на практике это не имело бы никакого значения (и мы хотим избежать взрыва целого числа проектов при каждой загрузке файла решения).

Мы выполняем нашу проверку частично в объектах POCO и на уровне обслуживания (который сопоставляет DTO с POCO и может проверять данные). Также мы проверяем входящие данные в докладчике и в javascript в представлении (для удобства пользователей). В настоящее время мы не используем инструмент для проверки.

И да, у нас есть тестовый проект для каждого слоя. Мы тестируем докладчиков, сервисы и UoW / репозитории. На нашем сервере сборки мы запускаем непрерывную интеграцию, которая запускает все модульные тесты в нескольких различных настройках (в памяти, для базы данных, с использованием WCF).

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

Единственное, на что я сейчас смотрю, это тестирование реальных представлений. В настоящее время мы не тестируем их автоматически. Может быть, мы собираемся использовать тесты Coded UI или какой-то фреймворк javascript.