Я пытался структурировать свои 3-уровневые приложения. Кажется, у меня всегда возникают проблемы с зависимостями, которые мне не нужны, что является верным признаком того, что я делаю что-то не так.
Как вы обычно структурируете свою 3-уровневую архитектуру?
Я вижу один из 2 способов сделать это:
- Бизнес-уровень находится вверху (или внизу, в зависимости от того, как вы на него смотрите), и все остальные слои зависят от него. Бизнес-уровень определяет интерфейсы, необходимые для его работы, особенно для доступа к данным. Уровень доступа к данным реализует эти интерфейсы, а Dependency Injection используется для внедрения их в средний уровень. Пользовательский интерфейс также использует выходные интерфейсы, опять же через DI. Бизнес-объекты - это POCO, которые заполняет слой данных. Уровень данных не имеет своей собственной модели кода (он использует бизнес-объекты, определенные в бизнес-уровне). Бизнес-уровень ничего не знает ни о пользовательском интерфейсе, ни об уровне данных, пользовательский интерфейс и уровень данных не знают о бизнес-уровне.
- Уровень пользовательского интерфейса вверху, Бизнес посередине, Данные внизу. Уровень данных публикует интерфейсы, используемые бизнес-уровнем. Бизнес имеет интерфейсы, которые использует пользовательский интерфейс. Это прямая ситуация 1-2-3. Уровень данных определяет объекты кода, бизнес-уровень имеет свою собственную модель (и что-то вроде AutoMapper используется для сопоставления между ними. Но это отображение выполняется на бизнес-уровне). Уровень данных ничего не знает о бизнес-уровне или уровне пользовательского интерфейса. Бизнес-уровень знает об уровне данных, но не о уровне пользовательского интерфейса. Уровень пользовательского интерфейса знает о бизнес-уровне, но не о уровне данных.
![enter image description here](https://i.stack.imgur.com/H3X61.png)
Вы используете какой-либо из них? Который из? Зачем? Вы используете другой подход?
С моей точки зрения, # 1 предлагает бизнес-ориентированный метод ведения дел. Пользовательский интерфейс может быть легко изменен, как и уровень данных, не затрагивая бизнес-уровень.
Второй вариант более понятен и обычно требует изменения бизнес-уровня при изменении уровня данных. Конечно, вы можете абстрагировать это с помощью хорошо спланированных интерфейсов (например, шаблон репозитория, но где-то это нужно изменить). Пользовательский интерфейс может быть изменен, не затрагивая либо.