Использование модели архитектуры Three-Tier

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

Ниже приведены краткие описания служб, выделенных для каждого уровня:

• Уровень презентации или уровень служб пользователей предоставляет пользователю доступ к приложению. Этот уровень представляет данные пользователю и при необходимости разрешает обработку данных и запись данных. Два основных типа пользовательского интерфейса для этого уровня — это традиционное приложение и веб-приложение. Веб-приложения теперь часто содержат большинство функций обработки данных, используемых традиционными приложениями. Это достигается с помощью динамических источников данных HTML и клиентских источников данных и курсоров данных.

  Заметка

  В трехуровневом приложении клиентское приложение будет тоньше, чем клиент-серверное приложение, так как оно не будет содержать компоненты обслуживания, расположенные на среднем звене. Это приводит к снижению нагрузки для пользователя, но больше сетевого трафика для системы, так как компоненты распределяются между разными компьютерами.

   

• Средний уровень, или уровень бизнес-служб, состоит из бизнес-правил и правил данных. Также называемый уровнем бизнес-логики, промежуточный слой позволяет разработчикам COM+ решать критически важные бизнес-задачи и получать значительные преимущества в производительности. Компоненты, составляющие этот уровень, могут существовать на серверном компьютере, чтобы помочь в совместном использовании ресурсов. Эти компоненты можно использовать для применения бизнес-правил, таких как бизнес-алгоритмы и юридические или государственные правила, а также правила данных, которые предназначены для обеспечения согласованности структур данных в пределах определенных или нескольких баз данных. Поскольку эти компоненты среднего уровня не привязаны к конкретному клиенту, они могут использоваться всеми приложениями и могут быть перемещены в разные расположения, так как требуется время отклика и другие правила. Например, простые изменения можно поместить на стороне клиента, чтобы свести к минимуму сетевые круговые пути, или правила данных можно поместить в хранимые процедуры.

• Уровень данных или уровень служб данных взаимодействует с постоянными данными, обычно хранящимися в базе данных или в постоянном хранилище. Это фактический уровень доступа к СУБД. Доступ к нему можно получить через уровень бизнес-служб и иногда с помощью уровня пользовательских служб. Этот уровень состоит из компонентов доступа к данным (а не необработанных подключений СУБД), которые помогают совместному использованию ресурсов и позволяют клиентам настраиваться без установки библиотек СУБД и драйверов ODBC на каждом клиенте.

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

Связанные разделы

логическая модель: определение приложения и планирование