В разработке мы понимаем уровень как абстракцию " уровень ответственности ".
Такой уровень ответственности группирует понятия вместе, чтобы обеспечить согласованное семантическое представление о реальности или, по крайней мере, нечто похожее на реальность.
В этом смысле так называемая трехуровневая модель или n-уровневые модели являются просто различными реализациями этих концепций.
Хорошим примером яруса является модель, в которой люди тщательно обращаются к соответствующим людям. Например, в обычном бизнесе есть отдел коммерции, маркетинга, систем, разработки и тестирования (например), которые представляют уровни бизнеса. Таким образом, обязанности ясны: разработка обеспечивает продукт, тестирование тестирует его, маркетинг продвигает его, а коммерческое продает его, и все это, в то время как системы поддерживают инфраструктуру (это только пример).
Эта метафора была впервые применена с 3-уровневой моделью, где определены три уровня. Обычно это уровни Уровень абстракции базы данных , который отвечает за связь и абстракцию над базой данных, Уровень бизнес-правил , который содержит правила, описывающие бизнес-процесс, и Пользователь Уровень интерфейса , который абстрагирует взаимодействие пользователя с системой.
Таким образом, у нас есть роли для обязанностей каждого уровня, так что если пользователю необходимо взаимодействовать с системой, он будет взаимодействовать с одним уровнем, а не путаться в дырочной системе.
N-уровень представляет собой эволюцию прежней концепции с использованием большего количества уровней для удовлетворения конкретных потребностей. Обычно уровень пользовательского интерфейса и уровень абстракции базы данных остаются нетронутыми, поскольку их роли достаточно ясны, а уровень бизнес-правил дорабатывается.
Для этого мы всегда учитываем характеристики проблемы, а также функции, которые мы хотим предоставить сейчас и в будущем. Например, если приложению нужно будет работать со смарт-клиентами или его предполагаемая работа со смарт-клиентами, тогда бизнес-уровень обычно делится на прокси-уровень и внутренний уровень, первый из которых направляет вызовы туда, куда они должны идти.
В конце концов, важна концепция отвлечения ответственности между различными уровнями и централизации всех связанных операций из семантического представления в одном месте.
Обратите внимание, что, кроме того, n-уровневая архитектура позволяет распределять эти "обязанности" среди разработчиков. Таким образом, данная группа может нести ответственность за уровень абстракции базы данных, в то время как другая группа работает на уровне прокси, а другая - на уровне абстракции графики. Когда члену группы требуется доступ к базе данных, он просматривает документацию DAL и использует одно из предоставленных средств или просит группу DAL предоставить необходимую ему функциональность, чтобы он не обращался непосредственно к базе данных, но через людей, которые лучше знают дизайн и тонкости самой базы данных.