Рис. 2
Включение слоя сервисов в приложение
Вданном сценарии пользователи могут выполнять доступ к приложению через слой представления, который обменивается данными с компонентами бизнес-слоя либо напрямую, либо через фасад приложения в бизнес-слое, если методы связи требуют композиции функциональности. Между тем, внешние клиенты и другие системы могут выполнять доступ к приложению и использовать его функциональность путем взаимодействия с бизнес-слоем через интерфейсы сервисов. Это улучшает возможности приложения для поддержки множества типов клиентов, способствует повторному использованию и более высокому уровню композиции функциональности в приложениях.
Внекоторых случаях слой представления может взаимодействовать с бизнес-слоем через слой сервисов. Но это не является обязательным условием. Если физически слой представления и бизнес-слой располагаются на одном уровне, они могут взаимодействовать напрямую. Проектированию слоя сервисов посвящена глава 9, «Рекомендации по проектированию слоя сервисов». Более подробно взаимодействие слоев рассматривается в главе 18, «Взаимодействие и обмен сообщениями».
Этапы проектирования многослойной структуры
Приступая к проектированию приложения, прежде всего, сосредоточьтесь на самом высоком уровне абстракции и начинайте с группировки функциональности в слои. Далее следует
определить открытый интерфейс для каждого слоя, который зависит от типа создаваемого приложения. Определив слои и интерфейсы, необходимо принять решение о том, как будет развертываться приложение. Наконец, выбираются протоколы связи для обеспечения взаимодействия между слоями и уровнями приложения. Несмотря на то, что разрабатываемая структура и интерфейсы могут изменяться со временем, особенно в случае применения гибкой разработки, следование этим этапам гарантированно обеспечит рассмотрение всех важных аспектов в начале процесса. Обычно при проектировании используется следующая последовательность шагов:
Шаг 1 – Выбор стратегии разделения на слои
Шаг 2 – Выбор необходимых слоев
Шаг 3 – Принятие решения о распределении слоев и компонентов
Шаг 4 – Выяснение возможности сворачивания слоев
Шаг 5 – Определение правил взаимодействия между слоями
Шаг 6 – Определение сквозной функциональности
Шаг 7 – Определение интерфейсов между слоями
Шаг 8 – Выбор стратегии развертывания
Шаг 9 – Выбор протоколов связи
Шаг 1 – Выбор стратегии разделения на слои
Разделение на слои представляет логическое распределение компонентов приложения по группам, выполняющим определенные роли и функции. Использование многослойного подхода может повысить удобство обслуживания приложения и упростить его масштабирование, если необходимо повысить производительность. Существует множество разных способов группировки взаимосвязанных функций в слои. Однако неправильное разделение на слои (слишком мало или слишком много) может лишь усложнить приложение, приводя к снижению общей производительности, удобства обслуживания и гибкости. Определение соответствующего уровня детализации при разделении приложения на слои – критически важный первый шаг в определении стратегии разделения на слои.
Также следует учесть, применяются ли слои исключительно для логического разделения либо для обеспечения физического разделения в случае необходимости. Пересечение границ слоев, особенно границ между физически удаленными компонентами, обусловливает возникновение издержек и снижение производительности. Однако общее повышение масштабируемости и гибкости приложения может быть намного более сильным аргументом по сравнению с падением производительности. Кроме того, разделение на слои может упростить оптимизацию производительности отдельных слоев без влияния на смежные слои.
В случае логического разделения взаимодействующие слои приложения будут развертываться на одном уровне и выполняться в одном процессе, что позволит применять более производительные механизмы связи, такие как прямые вызовы через интерфейсы компонентов. Однако чтобы воспользоваться преимуществами логического разделения на
слои и гарантировать гибкость в будущем, следует серьезно и тщательно подойти к вопросам обеспечения инкапсуляции и слабого связывания между слоями.
Для слоев, развертываемых на разных уровнях (разные физические компьютеры), взаимодействие со смежными слоями будет происходить по сети, и необходимо обеспечить, чтобы выбранный дизайн поддерживал подходящий механизм связи, который будет учитывать задержку связи и обеспечивать слабое связывание между слоями.
Определение того, какие слои приложения вероятнее всего будут развертываться на разных уровнях, а какие на одном, также является важной часть стратегии разделения на слои. Для обеспечения гибкости необходимо гарантированно обеспечить слабую связанность слоев. Это позволяет использовать преимущества большей производительности при размещении слоев на одном уровне и в случае необходимости развертывать их на множестве уровней.
Применение многослойного подхода может несколько усложнить дизайн и увеличить продолжительность подготовительного этапа разработки, но в случае правильной реализации существенно улучшит обслуживаемость, расширяемость и гибкость приложения. Сопоставьте преимущества, обеспечиваемые возможностью повторного использования и слабым связыванием при разделении на слои, с негативными последствиями их применения, такими как снижение производительности и повышение сложности. Тщательно продумайте, как разделить приложение на слои, и как слои будут взаимодействовать друг с другом; тем самым вы обеспечите хороший баланс производительности и гибкости. Как правило, выигрыш в гибкости и удобстве обслуживания, обеспечиваемый многослойной схемой, намного превышает сомнительное повышение производительности, которого можно достичь в тесно связанном дизайне, не использующем слои.
Описание общепринятых типов слоев и руководство по выбору необходимых слоев можно найти в разделе «Логическое разделение на слои» ранее в данной главе.
Шаг 2 – Выбор необходимых слоев
Существует множество разных способов группировки взаимосвязанных функций в слои. Самый распространенный в бизнес-приложениях подход – распределение функциональности представления, сервисов, доступа к данным и бизнес-функциональности по разным слоям. В некоторых приложениях также используются слои составления отчетов, управления и инфраструктуры.
Внимательно подходите к вопросу введения дополнительных слоев. Слой должен обеспечивать логическую группировку взаимосвязанных компонентов, которая заметно увеличивает удобство обслуживания, масштабируемость и гибкость приложения. Например, если приложение не предоставляет сервисы, возможно, отдельный слой сервисов не понадобится, тогда приложение будет включать только слой представления, бизнес-слой и слой доступа к данным.
Шаг 3 – Принятие решения о распределении слоев и компонентов
Слои и компоненты должны распределяться по разным физическим уровням, только если в этом есть необходимость. К типовым причинам реализации распределенного развертывания
относятся политики безопасности, физические ограничения, совместно используемая бизнеслогика и масштабируемость.
Если компоненты представления Веб-приложения осуществляют синхронный доступ к компонентам бизнес-слоя и ограничения безопасности не требуют наличия границы доверия между слоями, рассмотрите возможность развертывания компонентов бизнес-слоя и слоя представления на одном уровне, это обеспечит максимальную производительность и управляемость.
В насыщенных клиентских приложениях, в которых обработка UI выполняется на клиентском компьютере, вариант развертывания компонентов бизнес-слоя на отдельном бизнес-уровне может быть выбран по соображениями безопасности и для повышения управляемости.
Развертывайте бизнес-сущности на одном уровне с кодом, их использующим. Это может означать их развертывание в нескольких местах, например, размещение копий на отдельном уровне представления или данных, логика которого использует или ссылается на эти бизнес-сущности. Развертывайте компоненты агентов сервиса на том же уровне, что и код, вызывающий эти компоненты, если ограничения безопасности не требуют наличия границы доверия между ними.
Рассмотрите возможность развертывания асинхронных компонентов бизнес-слоя, компонентов рабочего процесса и сервисов с одинаковыми характеристиками загрузки и ввода/вывода на отдельном уровне. Это позволит настраивать инфраструктуру для обеспечения максимальной производительности и масштабируемости.
Шаг 4 – Выяснение возможности сворачивания слоев
В некоторых случаях имеет смысл свернуть слои. Например, в приложении, имеющем очень ограниченный набор бизнес-правил или использующем правила преимущественно для валидации, бизнес-логика и логика представления могут быть реализованы в одном слое. В приложении, которое просто извлекает данные с Веб-сервиса и отображает их, может иметь смысл просто добавить ссылки на Веб-сервис непосредственно в слой представления и использовать данные Веб-сервиса напрямую. В этом случае логически объединяются слои доступа к данным и представления.
Это лишь некоторые примеры того, когда имеет смысл сворачивание слоев. Тем не менее, группировка функциональности в слои является общим правилом. В некоторых случаях слой может выступать в роли проксиили транзитного уровня, который обеспечивает инкапсуляцию или слабое связывание практически без предоставления функциональности. Но отделение этой функциональности позволит расширять ее в будущем без оказания влияния или с небольшим влиянием на другие слои.
Шаг 5 – Определение правил взаимодействия между слоями
Когда дело доходит до стратегии разделения на слои, необходимо определить правила взаимодействия слоев друг с другом. Основная цель задания правил взаимодействия – минимизация зависимостей и исключение циклических ссылок. Например, если два слоя