Войти
В программной инженерии, многоуровневой архитектуры (часто упоминается как п -tier архитектуры ) или многослойной архитектуры является архитектура клиент-сервер, в котором функции представления, обработки приложений и управления данными физически разделены. Наиболее распространенным использованием многоуровневой архитектуры является трехуровневая архитектура.
N -уровневая архитектура приложений предоставляет модель, с помощью которой разработчики могут создавать гибкие и повторно используемые приложения. Разделив приложение на уровни, разработчики получают возможность изменять или добавлять определенный уровень вместо того, чтобы переделывать все приложение. Трехуровневая архитектура обычно состоит из уровня представления, логического уровня и уровня данных.
Хотя концепции уровня и уровня часто используются как взаимозаменяемые, одна довольно распространенная точка зрения состоит в том, что действительно существует разница. Эта точка зрения утверждает, что уровень - это механизм логического структурирования для элементов, составляющих программное решение, а уровень - это механизм физического структурирования для инфраструктуры системы. Например, трехуровневое решение можно легко развернуть на одном уровне, например на персональной рабочей станции.
Архитектурный паттерн «Слои» описан в различных публикациях.
В логической многоуровневой архитектуре информационной системы с объектно-ориентированным дизайном наиболее распространены следующие четыре:
В книге « Дизайн, управляемый доменом» описываются некоторые распространенные способы использования вышеуказанных четырех уровней, хотя основное внимание уделяется уровню предметной области.
Если в архитектуре приложения нет явного различия между бизнес-уровнем и уровнем представления (т. Е. Уровень представления считается частью бизнес-уровня), то была реализована традиционная модель клиент-сервер (двухуровневая).
Более обычным соглашением является то, что уровень приложения (или уровень сервиса) считается подуровнем бизнес-уровня, обычно инкапсулируя определение API, отображающее поддерживаемые бизнес-функции. Фактически, уровни приложения / бизнеса могут быть дополнительно разделены, чтобы выделить дополнительные подслои с отдельной ответственностью. Например, если используется шаблон модель – представление – презентатор, подуровень презентатора может использоваться как дополнительный уровень между уровнем пользовательского интерфейса и уровнем бизнеса / приложения (представленным подуровнем модели).
Некоторые также определяют отдельный уровень, называемый уровнем бизнес-инфраструктуры (BI), расположенный между бизнес-уровнем (-ами) и уровнем (-ами) инфраструктуры. Его также иногда называют «низкоуровневым бизнес-уровнем» или «уровнем бизнес-сервисов». Этот уровень является очень общим и может использоваться на нескольких уровнях приложения (например, CurrencyConverter).
Уровень инфраструктуры можно разделить на разные уровни (технические услуги высокого или низкого уровня). Разработчики часто сосредотачиваются на возможностях персистентности (доступа к данным) уровня инфраструктуры и поэтому говорят только об уровне постоянства или уровне доступа к данным (а не об уровне инфраструктуры или уровне технических услуг). Другими словами, другие виды технических услуг не всегда явно рассматриваются как часть какого-либо конкретного уровня.
Один слой находится поверх другого, потому что это зависит от него. Каждый слой может существовать без вышележащих слоев, и для работы требуются нижележащие слои. Другое распространенное мнение состоит в том, что слои не всегда строго зависят только от соседнего слоя ниже. Например, в расслабленной слоистой системе (в отличие от строгой слоистой системы) слой также может зависеть от всех нижележащих слоев.
Обзор трехуровневого приложения. Трехуровневая архитектура клиент-сервер шаблон архитектуры программного обеспечения, в которой пользовательский интерфейс (презентация), функциональная логика процесса ( «бизнес - правил»), для хранения компьютерных данных и доступа к данным разрабатываются и поддерживаются как независимые модули, чаще всего на отдельных платформах. Он был разработан Джоном Дж. Донованом из Open Environment Corporation (OEC), компании по производству инструментов, которую он основал в Кембридже, штат Массачусетс.
Помимо обычных преимуществ модульного программного обеспечения с четко определенными интерфейсами, трехуровневая архитектура позволяет независимо обновлять или заменять любой из трех уровней в ответ на изменения требований или технологий. Например, смена операционной системы на уровне представления повлияет только на код пользовательского интерфейса.
Обычно пользовательский интерфейс работает на настольном ПК или рабочей станции и использует стандартный графический интерфейс пользователя, функциональную логику процесса, которая может состоять из одного или нескольких отдельных модулей, работающих на рабочей станции или сервере приложений, и СУБД на сервере базы данных или мэйнфрейме, который содержит логику хранения компьютерных данных. Средний уровень может быть сам по себе многоуровневым (в этом случае общая архитектура называется « n- ступенчатой архитектурой»).
В области веб-разработки трехуровневый часто используется для обозначения веб-сайтов, обычно веб-сайтов электронной коммерции, которые построены с использованием трех уровней:
Передача данных между уровнями является частью архитектуры. Используемые протоколы могут включать в себя один или несколько из SNMP, CORBA, Java RMI, .NET Remoting, Windows Communication Foundation, сокеты, UDP, веб-службы или другие стандартные или проприетарные протоколы. Часто промежуточное ПО используется для соединения отдельных уровней. Отдельные уровни часто (но не обязательно) работают на отдельных физических серверах, и каждый уровень может работать в кластере.
Сквозная прослеживаемость потоков данных через n -уровневые системы - сложная задача, которая становится более важной, когда системы становятся более сложными. Параметр Application Response Measurement определяет концепции и API для измерения производительности и сопоставления транзакций между уровнями. Обычно термин «уровни» используется для описания физического распределения компонентов системы на отдельных серверах, компьютерах или сетях (узлах обработки). Тогда трехуровневая архитектура будет иметь три узла обработки. Термин «уровни» относится к логической группировке компонентов, которые могут или не могут быть физически расположены на одном узле обработки.
