Многоуровневая архитектура
 | Эта статья нуждается в дополнительных цитатах для проверки . ( январь 2008 г. ) |
В обеспечения разработке программного многоуровневая архитектура (часто называемая n -уровневой архитектурой ) представляет собой архитектуру клиент-сервер , в которой функции представления, обработки приложений и управления данными физически разделены. Наиболее распространенным применением многоуровневой архитектуры является трехуровневая архитектура .
N -уровневая архитектура приложений обеспечивает модель, с помощью которой разработчики могут создавать гибкие и повторно используемые приложения. Разделяя приложение на уровни, разработчики получают возможность изменять или добавлять определенный уровень вместо переделки всего приложения. N-уровневая архитектура хорошо подходит для небольших и простых приложений благодаря своей простоте и дешевизне. Кроме того, это может стать хорошей отправной точкой, когда архитектурные требования еще не ясны. [1] [2] Трехуровневая архитектура обычно состоит из уровня представления , логического уровня и уровня данных .
Хотя концепции уровня и уровня часто используются как взаимозаменяемые, довольно распространена точка зрения, что разница действительно существует. Согласно этой точке зрения, уровень — это механизм логического структурирования концептуальных элементов, составляющих программное решение, а уровень — это физический механизм структурирования аппаратных элементов, составляющих системную инфраструктуру. [3] [4] Например, трехуровневое решение можно легко развернуть на одном уровне, как в случае с экстремально ориентированной на базу данных архитектурой, называемой архитектурой только для СУБД. [5] или на личном рабочем месте. [6]
Слои [ править ]
«Слои» Архитектурный шаблон описан в различных публикациях. [7]
Общие слои [ править ]
В логической многоуровневой архитектуре информационной системы с объектно-ориентированным дизайном наиболее распространены следующие четыре:
- Уровень представления (он же уровень пользовательского интерфейса, уровень представления, уровень представления в многоуровневой архитектуре)
- Прикладной уровень (он же сервисный уровень) [8] [9] или GRASP уровень контроллера [10] )
- Бизнес-уровень (он же уровень бизнес-логики (BLL), уровень доменной логики)
- Уровень доступа к данным (он же уровень персистентности , журналирования, сети и другие сервисы, необходимые для поддержки определенного бизнес-уровня)
В книге «Проектирование, управляемое предметной областью» описаны некоторые распространенные варианты использования вышеупомянутых четырех уровней, хотя основное внимание уделяется уровню предметной области . [11]
Если в архитектуре приложения нет явного различия между бизнес-уровнем и уровнем представления (т. е. уровень представления считается частью бизнес-уровня), то реализуется традиционная клиент-серверная (двухуровневая) модель. [ нужна ссылка ]
Более распространенное соглашение заключается в том, что уровень приложения (или уровень обслуживания) считается подуровнем бизнес-уровня, обычно инкапсулируя определение API, отображающее поддерживаемые бизнес-функции. Фактически, уровни приложений/бизнеса могут быть подразделены, чтобы выделить дополнительные подуровни с отдельной ответственностью. Например, если модель-представление-презентатор , подуровень презентатора может использоваться в качестве дополнительного уровня между уровнем пользовательского интерфейса и уровнем бизнеса/приложения (как представлено подуровнем модели). используется шаблон [ нужна ссылка ]
Некоторые также выделяют отдельный уровень, называемый уровнем бизнес-инфраструктуры (BI), расположенный между бизнес-уровнями и уровнями инфраструктуры. Его также иногда называют «бизнес-уровнем низкого уровня» или «уровнем бизнес-услуг». Этот уровень является очень общим и может использоваться на нескольких уровнях приложения (например, CurrencyConverter). [12]
Уровень инфраструктуры можно разделить на разные уровни (технические услуги высокого и низкого уровня). [12] Разработчики часто сосредотачиваются на возможностях сохранения (доступа к данным) уровня инфраструктуры и поэтому говорят только об уровне постоянства или уровне доступа к данным (а не об уровне инфраструктуры или уровне технических услуг). Другими словами, другой вид технических услуг не всегда явно рассматривается как часть какого-либо конкретного уровня. [ нужна ссылка ] . Уровень доступа к данным обычно содержит объект, известный как объект доступа к данным (DAO) .
Слой находится поверх другого, потому что он от него зависит. Каждый уровень может существовать без слоев выше него и требует, чтобы уровни ниже него функционировали. Другая распространенная точка зрения заключается в том, что уровни не всегда строго зависят только от соседнего слоя, расположенного ниже. Например, в расслабленной многоуровневой системе (в отличие от строгой многоуровневой системы) уровень также может зависеть от всех слоев, расположенных ниже него. [7] Расслабленная многоуровневая система имеет больше связей, и впоследствии ее труднее изменить. В многоуровневых архитектурах может использоваться гибридный подход, при котором некоторые уровни являются строгими, а другие — смягченными. [13] [14]
Трехуровневая архитектура [ править ]
Трехуровневая архитектура — это модель клиент-серверной архитектуры программного обеспечения , в которой пользовательский интерфейс (презентация), функциональная логика процессов («бизнес-правила»), компьютерное хранилище данных и доступ к данным разрабатываются и поддерживаются как независимые модули , чаще всего на отдельных платформах. . [15] Он был разработан Джоном Дж. Донованом в Open Environment Corporation (OEC), инструментальной компании, которую он основал в Кембридже, штат Массачусетс .
Помимо обычных преимуществ модульного программного обеспечения с четко определенными интерфейсами, трехуровневая архитектура предназначена для независимого обновления или замены любого из трех уровней в ответ на изменения требований или технологий . Например, изменение операционной системы на уровне представления повлияет только на код пользовательского интерфейса.
Обычно пользовательский интерфейс запускается на настольном ПК или рабочей станции и использует стандартный графический интерфейс пользователя , логику функционального процесса, которая может состоять из одного или нескольких отдельных модулей, работающих на рабочей станции или сервере приложений , и СУБД на сервере базы данных или мейнфрейме , который содержит логику хранения компьютерных данных. Средний уровень сам может быть многоуровневым (в этом случае общая архитектура называется « n -уровневой архитектурой»).
- Уровень представления
- Это самый верхний уровень приложения. Уровень представления отображает информацию, связанную с такими услугами, как просмотр товаров, покупка и содержимое корзины покупок. Он взаимодействует с другими уровнями, посредством которых передает результаты на уровень браузера/клиента и на все остальные уровни в сети. Проще говоря, это уровень, к которому пользователи могут получить прямой доступ (например, веб-страница или графический интерфейс операционной системы).
- Уровень приложения (бизнес-логика, логический уровень или средний уровень)
- Логический уровень извлекается из уровня представления и в качестве его уровня управляет функциональностью приложения, выполняя детальную обработку.
- Уровень данных
- Уровень данных включает в себя механизмы сохранения данных (серверы баз данных, общие файловые ресурсы и т. д.) и уровень доступа к данным, который инкапсулирует механизмы сохранения и предоставляет данные. Уровень доступа к данным должен предоставлять API-интерфейс для уровня приложений, который предоставляет методы управления хранимыми данными без раскрытия или создания зависимостей от механизмов хранения данных. Избежание зависимостей от механизмов хранения позволяет вносить обновления или изменения без влияния на клиенты уровня приложений или даже без их ведома об этих изменениях. Как и при разделении любого уровня, существуют затраты на внедрение и зачастую снижение производительности в обмен на улучшение масштабируемости и удобства обслуживания.
Использование веб-разработки [ править ]
В области веб-разработки термин «три уровня» часто используется для обозначения веб-сайтов , обычно веб-сайтов электронной коммерции , которые построены с использованием трех уровней:
- Интерфейсный веб-сервер, обслуживающий статический контент и, возможно, некоторый кэшированный динамический контент. В веб-приложении интерфейс — это контент, отображаемый браузером. Содержимое может быть статическим или генерироваться динамически.
- среднего динамического уровня обработки контента и генерации Сервер приложений (например, Symfony , Spring , ASP.NET , Django , Rails , Node.js ).
- Внутренняя база данных или хранилище данных , содержащая как наборы данных, так и программное обеспечение системы управления базами данных , которое управляет данными и обеспечивает доступ к ним.
Другие соображения [ править ]
Передача данных между уровнями является частью архитектуры. Используемые протоколы могут включать один или несколько из SNMP , CORBA , Java RMI , .NET Remoting , Windows Communication Foundation , сокетов , UDP , веб-служб или других стандартных или проприетарных протоколов. Часто промежуточное программное обеспечение используется для соединения отдельных уровней. Отдельные уровни часто (но не обязательно) выполняются на отдельных физических серверах, и каждый уровень сам по себе может работать в кластере .
Прослеживаемость [ править ]
Сквозное отслеживание потоков данных через n- уровневые системы — сложная задача, которая становится более важной, когда системы усложняются. Измерение отклика приложения определяет концепции и API для измерения производительности и корреляции транзакций между уровнями. Обычно термин «уровни» используется для описания физического распределения компонентов системы на отдельных серверах, компьютерах или сетях (узлах обработки). Тогда трехуровневая архитектура будет иметь три узла обработки. Термин «уровни» относится к логической группе компонентов, которые могут или не могут быть физически расположены на одном узле обработки.
См. также [ править ]
- Слой абстракции
- Модель клиент-сервер
- Архитектура, ориентированная на базу данных
- Фронтенд и бэкенд
- Иерархическая модель межсетевого взаимодействия
- Балансировка нагрузки (вычисления)
- Монолитное приложение
- Открытая архитектура сервисов
- Богатое веб-приложение
- Сервисный уровень
- Срез слоев
- Веб-приложение
Ссылки [ править ]
- ^ Ричардс, Марк (2020). Основы архитектуры программного обеспечения: инженерный подход (1-е изд.). О'Рейли Медиа. ISBN 978-1492043454 .
- ^ Ричардс, Марк (2022). Шаблоны архитектуры программного обеспечения . O'Reilly Media, Inc. ISBN 9781098134273 .
- ^ Шаблоны развертывания (архитектура, шаблоны и практики Microsoft Enterprise)
- ^ Фаулер, Мартин «Образцы архитектуры корпоративных приложений» (2002). Эддисон Уэсли.
- ^ Висенте, Альфонсо; Эчеверри, Лорена; Сабигеро, Ариэль (2021). «Архитектура веб-приложений, основанная только на СУБД» . XLVII Латиноамериканская компьютерная конференция (CLEI) 2021 г. стр. 1–9. дои : 10.1109/CLEI53233.2021.9640017 . ISBN 978-1-6654-9503-5 . S2CID 245387844 .
- ^ Шаблоны развертывания (архитектура, шаблоны и практики Microsoft Enterprise)
- ↑ Перейти обратно: Перейти обратно: а б Бушманн, Франк; Менье, Регина; Ронерт, Ганс; Соммерлад, Питер; Сталь, Михаил (1996–08). Шаблонно-ориентированная архитектура программного обеспечения, Том 1, Система шаблонов. Уайли, август 1996 г. ISBN 978-0-471-95869-7 . Получено с http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471958697.html .
- ^ Уровень обслуживания Мартина Фаулера
- ^ Мартин Фаулер объясняет, что уровень обслуживания — это то же самое, что уровень приложения.
- ^ Сравнение/обсуждение уровня контроллера GRASP и уровня приложения/сервиса.
- ^ Проектирование, управляемое предметной областью, Книга, стр. 68-74. Получено с http://www.domaindrivendesign.org/books#DDD .
- ↑ Перейти обратно: Перейти обратно: а б Применение UML и шаблонов , 3-е издание, стр. 203 ISBN 0-13-148906-2
- ^ Ричардс, Марк (3 марта 2020 г.). Основы архитектуры программного обеспечения: инженерный подход (1-е изд.). О'Рейли Медиа. ISBN 978-1492043454 .
- ^ Ричардс, Марк. Шаблоны архитектуры программного обеспечения . О'Рейли Медиа, Инк.
- ^ Экерсон, Уэйн В. «Трехуровневая архитектура клиент/сервер: достижение масштабируемости, производительности и эффективности в приложениях клиент-сервер». Открытые информационные системы 10, 1 (январь 1995 г.): 3 (20)