3-х уровневая архитектура - PullRequest
3 голосов
/ 26 февраля 2012

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

Как вы обычно структурируете свою 3-уровневую архитектуру?

Я вижу один из 2 способов сделать это:

  1. Бизнес-уровень находится вверху (или внизу, в зависимости от того, как вы на него смотрите), и все остальные слои зависят от него. Бизнес-уровень определяет интерфейсы, необходимые для его работы, особенно для доступа к данным. Уровень доступа к данным реализует эти интерфейсы, а Dependency Injection используется для внедрения их в средний уровень. Пользовательский интерфейс также использует выходные интерфейсы, опять же через DI. Бизнес-объекты - это POCO, которые заполняет слой данных. Уровень данных не имеет своей собственной модели кода (он использует бизнес-объекты, определенные в бизнес-уровне). Бизнес-уровень ничего не знает ни о пользовательском интерфейсе, ни об уровне данных, пользовательский интерфейс и уровень данных не знают о бизнес-уровне.
  2. Уровень пользовательского интерфейса вверху, Бизнес посередине, Данные внизу. Уровень данных публикует интерфейсы, используемые бизнес-уровнем. Бизнес имеет интерфейсы, которые использует пользовательский интерфейс. Это прямая ситуация 1-2-3. Уровень данных определяет объекты кода, бизнес-уровень имеет свою собственную модель (и что-то вроде AutoMapper используется для сопоставления между ними. Но это отображение выполняется на бизнес-уровне). Уровень данных ничего не знает о бизнес-уровне или уровне пользовательского интерфейса. Бизнес-уровень знает об уровне данных, но не о уровне пользовательского интерфейса. Уровень пользовательского интерфейса знает о бизнес-уровне, но не о уровне данных.

enter image description here

Вы используете какой-либо из них? Который из? Зачем? Вы используете другой подход?

С моей точки зрения, # 1 предлагает бизнес-ориентированный метод ведения дел. Пользовательский интерфейс может быть легко изменен, как и уровень данных, не затрагивая бизнес-уровень.

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

1 Ответ

0 голосов
/ 22 марта 2012

если это приложение CURD с небольшой бизнес-логикой, используйте подход № 2. в противном случае используйте подход № 1, это на самом деле результат применения Inversion of Control (IoC) к # 2.

...