Архитектура: принципы создания нескольких слоев - PullRequest
1 голос
/ 01 декабря 2011

Как мы знаем, почти каждая сложная архитектура содержит несколько слоев. В системе управления мы можем без труда придумать уровень доступа к данным, уровень бизнес-логики и уровень представления. Я хочу знать, существует ли четкий принцип создания нескольких слоев. PS: Это не ограничивается системой управления.

Ответы [ 3 ]

1 голос
/ 02 декабря 2011

Я полагаю, что основным принципом наслоения является Разделение проблем . На самом деле он не привязан к объектно-ориентированному проектированию, но распространяется на всю программную инженерию (в статье в википедии приведен протокол стека).

Таким образом, обычно мы находим функциональные области (F1, F2, F3) и заставляем себя проектировать компоненты, которые выполняют только одну из них. Мы спрашиваем "Что значит Х"? и если ответите, если «F1, F2, F3», мы разделим X на X1, X2, X3, которые выполняют по одной функции каждый, но делают это хорошо.

Просто краткое и преувеличенное пример

class SomeBusinessObject //Business logic, as we think
{
    bool HasAccess(User loggedInUser)
    {
           /* two lines below are clearly from DataAccess layer */
           string q = "select 1 from user_roles where id={0} and isadmin=1";
           bool hasAccess = DataAccess.Execure(q).Rows > 0;
           if(!hasAccess)
           {
                /* message pre-formatting is Presentation layer concern */
                var msg = string.Format("<b>You don't have access</b>";
                throw new SecurityException(msg);
           }
           return true;
    }
}

В приведенном выше примере наш BL-класс должен знать о модели данных и деталях доступа к данным; также он пытается предварительно отформатировать сообщения для html-интерфейса. Так что, вероятно, мы переместим форматирование в представление; и извлеките создание SQL-запроса в DAL.

В общем случае могут быть следующие слои:

  1. Презентационный слой
    • Слой рендеринга пользовательского интерфейса (обычно представления)
    • Логика представления (презентаторы / контроллеры)
  2. Уровень обслуживания (может быть опущен в относительно небольших системах)
  3. Бизнес логика. Если мы хотим сделать это, мы могли бы подумать о:
    • Уровень бизнес-правил.
    • Валидационный слой.
    • Сама бизнес-логика.
    • Преобразование данных
    • Запрос услуг
  4. Доступ к данным. Можно разделить на два слоя:
    • Абстрактный доступ к данным, обслуживающий бизнес-уровни
    • Точные реализации ниже, слой "DB".

В общем, есть два правила отношений между слоями:

  1. Слой должен «общаться» только с нижележащими слоями. (Например, не должно быть никаких зависимостей, скажем, от BL до Presentation, от DAL до BL).
  2. Слой не должен «перепрыгивать» через слой. (Презентация не должна разговаривать с DAL).

Однако существуют также сквозные функции, которые на самом деле не связаны ни с одним из слоев. Это в основном относится к ведению журналов, кешированию и т. Д. Некоторые также могут сказать о безопасности, но я почти уверен, что это можно сделать в зависимости от уровня.

Надеюсь, это поможет.

1 голос
/ 02 декабря 2011

Многоуровневый архитектурный стиль подразумевает иерархию вызовов. для того, чтобы что-то считалось отдельным уровнем, его шаблоны связи с другими уровнями должны быть ограничены. слой предоставляет возможности слоям над ним и использует возможности из слоев выше. В чисто многоуровневых системах уровень может видеть только один шаг в иерархии (например, архитектура протокола TCP / IP).

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

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

1 голос
/ 01 декабря 2011

В разработке программного обеспечения при проектировании систем необходимо придерживаться определенных принципов проектирования. Если вы делаете это правильно, слои в значительной степени появляются сами по себе. Вот некоторые из принципов:

  1. Open / Closed
  2. Одиночная ответственность
  3. Разделение интерфейса
  4. Эквивалентность повторного использования выпуска
  5. Общее закрытие

Есть и другие. Вы можете прочитать о них в Интернете или получить книгу Роберта Мартина под названием « Agile Software Development, Принципы, Шаблоны и Практики »

Вот ссылка на соответствующую главу из книги.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...