Как организовать зависимости в 3-уровневой архитектуре

Question

Я начинаю проект, который будет использовать трехуровневую архитектуру с REST API.

Я хотел бы разделить каждый слой в отдельный модуль, так что я, безусловно, необходимо, по крайней мере 3 модулей:

• ОСТАЛЬНЫЕ
• BLL
• DAL

Каков наилучший подход устанавливать зависимости между ними:

1)

• REST зависит от BLL
• BLL зависит от DAL
• DAL зависит ни от чего

2)

• остальное зависит от ничего
• BLL зависит от REST
• DAL зависит от BLL

3)

• остальное зависит от REST-BLL-интерфейсов
• REST-BLL-интерфейсы зависят ни от чего
• БЛЛЫ зависят от REST-BLL-интерфейсов и Dal-BLL-интерфейсы
• DAL-BLL-интерфейсы depenends на ничего
• DAL зависит от Dal-БЛЛ-интерфейсы

Третий подход, по-видимому, наиболее совместим с принципом инверсии зависимостей, но требует больше модулей. Как бы вы назвали эти два дополнительных модуля?

Answer 1

Я бы сохранил ваш код BLL в проекте под названием Сервисы, ваш код DAL в проекте под названием «Репозитории», а также ваши интерфейсы и бизнес-объекты (или сущности) в проекте Core.

Ваш проект REST должен ссылаться только на Core (и Services для разрешения зависимостей). Вы программируете исключительно для интерфейсов. Вы также можете использовать Принцип DI здесь, как вы заявили.

Ваши сервисы и хранилища должны зависеть только от Core.Эти конкретные реализации нуждаются только в реализации основных интерфейсов и действуют на основные объекты.

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

Боковое примечание. Я часто включаю в себя еще один проект под названием «Инфраструктура» для обработки сквозных задач, таких как ведение журнала. Эти конкретные классы реализуют базовые интерфейсы, как и мои репозитории и службы, и могут быть вызваны с использованием интерфейсов.

Answer 2

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

Обычно я делаю это так или хочу прямо для первого варианта, и я не беспокоюсь об этом, поскольку я рассчитываю на то, что мои другие разработчики совместного заговорщика имеют некоторое чувство разделения архитектуры. В прошлом я использовал «архитектурные» аспекты для предотвращения перескакивания слоев, но для этого вам нужно включить поддержку компилятора аспекта в своей сборке/IDE.