Somasegar S., Guthrie Scott. Руководство Microsoft по проектированию архитектуры приложений

Подождите немного. Документ загружается.

Более подробно методики валидации рассматриваются в главе 17, «Сквозная

функциональность».

Вопросы проектирования слоев

В следующих разделах описываются специальные аспекты, которые необходимо принять во

внимание при проектировании слоев многослойного приложения.

Слой представления

Слой представления Веб-приложения обеспечивает отображение UI и взаимодействие с

пользователем. Дизайн должен разделять функциональные области, т.е. логика

взаимодействия с пользователем должна быть отделена от компонентов UI. В сложных

интерфейсах используйте отдельные компоненты UI и компоненты логики представления, и по

возможности создавайте компоненты UI на базе стандартных элементов управления Веб.

Элементы управления могут быть скомпилированы в сборку для повторного использования в

других приложениях или в случае необходимости введения дополнительных функций в

существующие серверные элементы управления.

Слой представления Веб-приложения состоит из серверных компонентов (которые формируют

визуальное отображение HTML) и клиентских компонентов (браузер или агент пользователя,

которые выполняют сценарии и отображают HTML). Как правило, вся логика представления

располагается в серверных компонентах, а клиентские компоненты только отображают HTML.

Такие клиентские технологии, как AJAX, позволяют выполнять логику на клиенте. Обычно это

делается для улучшения взаимодействия с пользователем, но для этого требуются

дополнительная разработка и тестирование. Если принято решение выполнять какую-то

проверку на стороне клиента, не забудьте продублировать эту же проверку на сервере,

поскольку любая валидация на клиенте может быть подделана.

Бизнес-слой

При проектировании бизнес-слоя Веб-приложения необходимо продумать реализацию

бизнес-логики и длительных рабочих процессов. Использование выделенного бизнес-слоя,

который будет реализовывать бизнес-логику и рабочие процессы, может упростить

обслуживание и улучшить тестируемость приложения, а также позволит централизовать и

повторно использовать общие функции бизнес-логики. Проектируйте бизнес-сущности,

представляющие реальные данные, и используйте их для передачи данных между

компонентами.

Проектируйте бизнес-слой без сохранения состояния, это поможет сократить конкуренцию за

ресурсы и повысить производительность. Используйте интерфейс взаимодействия на основе

сообщений, это замечательный вариант для бизнес-слоя без сохранения состояния для Веб-

приложения. В случае осуществления в бизнес-слое критических бизнес-операций используйте

транзакции для обеспечения целостности данных и предотвращения их утери.

Слой доступа к данным

В слое доступа к данным Веб-приложения абстрагируйте логику, необходимую для доступа к

базе данных. Использование отдельного слоя доступа к данным упрощает конфигурацию и

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

приложения. Проектируйте объекты сущностей, которые могут заполняться слоем доступа к

данным или использоваться для обновления источника данных, и применяйте объекты

передачи данных (DTO) для взаимодействия с другими слоями и передачи данных между

слоями.

Использование в слое доступа к данным пула подключений позволит сократить число

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

данных. Слою доступа к данным также может понадобиться работать с внешними сервисами

через агенты сервисов. Не забудьте выработать стратегию обработки исключений,

обеспечивающую обработку ошибок доступа к данным и передачу исключений на бизнес-

слой.

Слой сервисов

Проектируйте отдельный слой сервисов, если планируется развертывать бизнес-слой

удаленно или предполагается предоставлять бизнес-логику через Веб-сервис. Отсутствие

конкретизации деталей клиентов, которые будут использовать сервисы, обеспечит

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

изменений, которые могут нарушить интерфейс сервиса для существующих клиентов.

Реализация версий интерфейса позволит клиентам подключаться к соответствующей версии

интерфейса.

Если бизнес-слой располагается удаленно, проектируйте слабо детализированные методы

сервисов, чтобы сократить количество обращений к сети и обеспечить слабое связывание.

Также обеспечьте идемпотентность (т.е. возможность обработки ситуации, когда один и тот же

запрос поступает несколько раз) и коммутативность (т.е. возможность обработки ситуации,

когда сообщения, осуществляющие определенную последовательность задач, поступают в

произвольном порядке) сервисов. Не реализуйте бизнес-правила в интерфейсе сервиса, это

может создать ненужные зависимости между компонентами и клиентами и усложнить задачу

по поддержанию стабильности интерфейса.

Наконец, выполните требования по обеспечению возможности взаимодействия, выбирая

соответствующие протоколы и механизмы транспортировки. Например, используйте ASMX для

общего и WCF для более детального управления конфигурацией. Примите решение о том,

будет ли интерфейс предоставлять методы SOAP, REST или оба типа методов. Более подробно

сервисы рассматриваются в главе 9, «Рекомендации по проектированию слоя сервисов», и

главе 18, «Взаимодействие и обмен сообщениями».

Вопросы тестирования и тестируемости

Тестируемость – это мера того, насколько легко создавать критерии проверки для системы

или компонентов и насколько хорошо они подвергаются тестированию на соответствие этим

критериям. Учитывать аспекты тестируемости при проектировании архитектуры необходимо

для того, чтобы обеспечить раннюю диагностику проблем и, таким образом, сократить затраты

на обслуживание. Для обеспечения тестируемости:

 Четко определяйте ввод и вывод слоев и компонентов приложения уже на этапе

проектирования.

 Используйте для слоя представления шаблоны отделения представления, такие как

MVC или MVP. Это обеспечит возможность модульного тестирования логики

представления.

 Реализуйте бизнес-логику и рабочие процессы в отдельном бизнес-слое, что

улучшит тестируемость приложения.

 Проектируйте слабо связанные компоненты, которые можно тестировать по

отдельности.

 Выработайте эффективную стратегию протоколирования и трассировки, что

позволит выявлять или диагностировать ошибки, которые в противном случае было

бы сложно найти. Обеспечьте данные протоколирования и трассировки, которые

могут использоваться средствами мониторинга или управления. Это поможет

обнаруживать дефектный код при возникновении ошибок. Файлы журнала должны

содержать сведения, которые можно использовать для воссоздания проблемы.

Вопросы выбора технологий

В ASP.NET модель ASP.NET Web Forms можно сочетать с широкой номенклатурой других

технологий, включая ASP.NET AJAX, ASP.NET MVC, Silverlight и ASP.NET Dynamic Data. Примите

во внимание следующие рекомендации:

 Используйте ASP.NET для создания приложений, доступ к которым осуществляется

через Веб-браузер, или специализированного агента пользователя.

 Используйте ASP.NET и AJAX для создания приложений, обеспечивающих

повышенные возможности взаимодействия с пользователем и фоновую обработку

с меньшим количеством перезагрузок страниц.

 Используйте ASP.NET и элементы управления Silverlight для создания приложений,

которые включают насыщенное медиа-содержимое и расширенные возможности

взаимодействия с пользователем.

 При использовании ASP.NET позаботьтесь о предоставлении шаблонов страниц для

реализации единообразного UI для всех страниц.

 Используйте ASP.NET Dynamic Data для создания управляемого данными Веб-

приложения, страницы которого формируются на основании модели данных

базовой базы данных.

 При использовании разработки через тестирование или в случае необходимости

обеспечить детализированное управление UI применяйте шаблон MVC и ASP.NET

MVC. Это позволит четко отделить логику приложения и навигации от UI

приложения.

Вопросы выбора стратегии развертывания

При развертывании Веб-приложения необходимо учесть то, как размещение слоев и

компонентов будет влиять на производительность, масштабируемость и безопасность

приложения. Возможно, придется пойти на некоторые компромиссы. В зависимости от бизнес-

требований и ограничений инфраструктуры используйте либо распределенное, либо

нераспределенное развертывание. Нераспределенное развертывание, как правило, приводит

к повышению производительности за счет снижения числа вызовов через физические

границы. Однако распределенное развертывание позволит обеспечить лучшую

масштабируемость и реализовать защиту каждого слоя в отдельности.

Нераспределенное развертывание

В сценарии нераспределенного развертывания все логически разделенные слои Веб-

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

Необходимо продумать, как приложение будет реализовывать параллельную работу

множества пользователей и как защитить слои, находящиеся на одном сервере. Этот сценарий

представлен на рис. 2.

Рис. 32

Нераспределенное развертывание Веб-приложения

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

 Используйте нераспределенное развертывание, если Веб-приложение

чувствительно к производительности, поскольку локальные вызовы между слоями

не имеют столь пагубного влияния на производительность, как удаленные вызовы

между уровнями.

 Если с бизнес-логикой будет работать только слой представления и не требуется

обеспечивать ее совместное использование другими приложениями, проектируйте

для бизнес-слоя компонентный интерфейс.

 Если бизнес-логика и логика представления выполняются в одном процессе,

избегайте аутентификации в бизнес-слое.

 Для доступа к базе данных используйте доверенное удостоверение (через модель

доверенной подсистемы). Это повысит производительность и масштабируемость

приложения.

 Продумайте, как будет реализована защита конфиденциальных данных,

передаваемых между Веб-сервером и сервером базы данных.

Распределенное развертывание

В сценарии распределенного развертывания слой представления и бизнес-слой Веб-

приложения располагаются на разных уровнях и взаимодействуют удаленно. Как правило,

бизнес-слой и слой доступа к данным размещаются на одном сервере. Рис. 2 демонстрирует

такой сценарий.

Рис. 3

Распределенное развертывание Веб-приложения

При выборе распределенного развертывания руководствуйтесь следующими

рекомендациями:

 Не развертывайте бизнес-слой на отдельном уровне без крайней необходимости;

например, чтобы увеличить масштабируемость, или если соображения

безопасности запрещают развертывание бизнес-логики на внешнем Веб-сервере.

 Используйте для бизнес-слоя интерфейс взаимодействия на основе сообщений.

 Используйте для взаимодействия с бизнес-слоем TCP-протокол с бинарным

кодированием. Это обеспечит лучшую производительность.

 Предусмотрите защиту конфиденциальных данных, передаваемых между разными

уровнями.

Балансировка нагрузки

Если Веб-приложение развертывается на множестве серверов, балансировка нагрузки

обеспечит распределение запросов и их обработку различными Веб-серверами. Такой подход

обеспечит меньшее время отклика, лучшее использование ресурсов и пропускную

способность. Этот сценарий продемонстрирован на рис. 4.

Рис. 4

Балансировка нагрузки Веб-приложения

При проектировании балансировки нагрузки для Веб-приложения руководствуйтесь

следующими рекомендациями:

 При проектировании Веб-приложения по возможности избегайте привязки к

одному серверу, поскольку это может негативно сказаться на возможности

масштабирования приложения. Привязка к серверу возникает, когда создаются

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

сервером. Обычно это происходит при использовании локально обновляемых

кэшей, хранения состояния сеансов в процессе или локальных хранилищ состояния

сеансов. Если требуется поддерживать привязку к одному серверу, конфигурируйте

кластер так, чтобы он обеспечивал маршрутизацию всех запросов от определенного

пользователя к одному и тому же серверу.

 Проектируйте для Веб-приложения компоненты без сохранения состояния;

например, Веб-интерфейс без промежуточного состояния и без бизнес-

компонентов, сохраняющих состояние. Если требуется сохранять состояние

пользователей, избегайте применения в Веб-ферме управления сеансами в

процессе, если не можете настроить привязку к серверу и гарантировать, что

запросы от одного пользователя будут направляться на один и тот же сервер. Лучше

используйте внешний сервис хранения состояния или сервер базы данных.

 Используйте Windows Network Load Balancing (NLB)

для реализации

перенаправления запросов на серверы фермы приложений.

 Используйте кластеризацию для сокращения негативных последствий сбоев

оборудования.

Система балансировки сетевой нагрузки Windows (прим. переводчика).

 Если приложению предъявляются высокие требования по вводу/выводу,

выполняйте секционирование базы данных и распределение ее на множество

серверов баз данных.

Более подробно шаблоны развертывания рассматриваются в главе 19, «Физические уровни и

развертывание».

Шаблоны проектирования

Основные шаблоны проектирования организованы по категориям, таким как Кэширование,

Управление исключениями, Протоколирование и инструментирование, Компоновка страницы,

Представление, Обработка запросов и Слой интерфейса сервиса, и представлены в следующей

таблице. Рассмотрите возможности применения этих шаблонов при принятии проектных

решений для каждой из категорий.

Категория

Шаблоны

Кэширование

Cache Dependency. Использует внешние данные для определения

состояния данных, хранящихся в кэше.

Page Cache. Улучшает время отклика динамических Веб-страниц,

доступ к которым осуществляется довольно часто, но сами они

меняются реже и потребляют большое количество ресурсов системы

для воссоздания.

Управление исключениями

Exception Shielding. При возникновении исключения предотвращает

предоставление сервисом данных о его внутренней реализации.

Протоколирование и

инструментирование

Provider. Реализует компонент, который предоставляет API,

отличающийся от клиентского API, обеспечивая возможность

подключения любой специальной реализации.

Компоновка страницы (UI)

Composite View. Сочетает отдельные представления в композитное

представление.

Template View. Реализует представление общего шаблона и создает

представления на базе этого шаблонного представления.

Transform View. Преобразует данные, переданные на уровень

представления, в HTML для отображения в UI.

Two-Step View. Преобразует модель данных в логическое

представление без какого-либо специального форматирования и затем

преобразует это логическое представление, добавляя необходимое

форматирование.

Представление

Model-View-Controller (Модель-Представление-Контроллер). На

основании пользовательского ввода распределяет данные предметной

области, представления и действий в три разных класса. Модель

управляет поведением и данными предметной области приложения,

отвечает на запросы о состоянии (обычно поступающие от

Представления) и на команды на изменение состояния (обычно

поступающие от Контроллера). Представление управляет

отображением данных. Контроллер интерпретирует ввод пользователя,

поступающий с устройств ввода, таких как мышь и клавиатура, и дает

указания модели и/или представлению о соответствующих изменениях.

Model-View-Presenter (Модель-Представление-Презентатор).

Разделяет обработку запроса на три отдельные роли, где

Представление отвечает за обработку пользовательского ввода,

Модель – за данные приложения и бизнес-логику, и Презентатор – за

логику представления и координирование взаимодействия между

Представлением и Моделью.

Passive View. Разновидность шаблона MVC. Сокращает представление

до необходимого минимума, перенося в контроллер функциональность

обработки пользовательского ввода и реализацию обновления

представления.

Supervising Presenter (или Supervising Controller). Разновидность

шаблона MVC, где контроллер отвечает за обработку сложной логики, в

частности, согласование представлений, а представление отвечает за

простую логику, касающуюся представления.

Обработка запросов

Intercepting Filter. Цепочка пригодных для компоновки фильтров

(независимые модули), реализующих обычные задачи предварительной

и последующей обработки при запросе Веб-страницы.

Page Controller. Принимает ввод из запроса и обрабатывает его для

конкретной страницы или действия Веб-сайта.

Front Controller. Консолидирует обработку запросов путем

направления всех запросов через один объект-обработчик, который

можно изменять во время выполнения с помощью декораторов.

Слой интерфейса

сервиса

Façade. Реализует унифицированный интерфейс для набора операций,

чтобы обеспечить упрощенный интерфейс и уменьшить связанность

систем.

Service Interface. Программный интерфейс, который может

использоваться другими системами для взаимодействия с сервисом.

Более подробно шаблон Page Cache рассматривается в статье «Enterprise Solution Patterns Using

Microsoft .NET» по адресу http://msdn.microsoft.com/en-us/library/ms998469.aspx.

Более подробно шаблоны Model-View-Controller (MVC), Page Controller, Front Controller,

Template View, Transform View и Two-Step View рассматриваются в книге Мартина Фаулера

«Архитектура корпоративных приложений». Addison-Wesley, 2002. Или по адресу

http://martinfowler.com/eaaCatalog.

Более подробно шаблоны Composite View, Supervising Presenter и Presentation Model

рассматриваются в статье «Patterns in the Composite Application Library» по адресу

http://msdn.microsoft.com/en-us/library/cc707841.aspx.

Более подробно шаблон Exception Shielding рассматривается в статье «Useful Patterns for

Services» по адресу http://msdn.microsoft.com/en-us/library/cc304800.aspx.

Более подробно шаблон Service Interface рассматривается в статье «Service Interface»

(Интерфейс сервиса) по адресу http://msdn.microsoft.com/en-us/library/ms998421.aspx.

Более подробно шаблон Provider рассматривается в статье «Provider Model Design Pattern and

Specification, Part I» по адресу http://msdn.microsoft.com/en-us/library/ms998421.aspx.

Дополнительные источники

Электронная версия списка используемых источников доступна по адресу

http://www.microsoft.com/architectureguide.

 Более подробно проектирование и реализация клиентских Веб-приложений

рассматривается в статье «Design and Implementation Guidelines for Web Clients» по

адресу http://msdn.microsoft.com/en-us/library/ms978605.aspx.

 Проектированию распределенных Веб-приложений посвящена статья «Designing

Distributed Applications» (Проектирование распределенных приложений) по адресу

http://msdn.microsoft.com/en-us/library/aa292470(VS.71).aspx.

 Вопросы производительности Веб-приложения подробно рассматриваются в статье

«Improving .NET Application Performance and Scalability» (Улучшение

производительности и масштабируемости .NET-приложений) по адресу

http://msdn.microsoft.com/en-us/library/ms998530.aspx.

 Безопасности Веб-приложений посвящена статья «Improving Web Application

Security: Threats and Countermeasures» (Повышение безопасности Веб-приложений:

угрозы и меры противодействия им) по адресу http://msdn.microsoft.com/en-

us/library/ms994921.aspx.

Проектирование насыщенных

клиентских приложений

Обзор

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

приложений, их компоненты и важные аспекты проектирования. Также будут рассмотрены

сценарии развертывания насыщенных клиентских приложений, основные шаблоны и

технологии их проектирования.

Пользовательские интерфейсы насыщенных клиентов могут обеспечивать высокую

производительность, интерактивность и насыщенное взаимодействие с пользователем для

приложений, которые должны работать как самодостаточные приложения и в сценариях с

подключением, без постоянного подключения и без подключения. Windows Forms, Windows

Presentation Foundation (WPF) и Microsoft Office Business Application (OBA) – все это доступные

среды и инструменты разработки, позволяющие разработчикам быстро и без труда создавать

насыщенные клиентские приложения.

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

приложений, выполняющихся на клиентском компьютере, но взаимодействующих с

сервисами, предоставляемыми другими уровнями (как логическими, так и физическими), и

другими приложениями, предоставляющими операции, которые необходимы клиенту. К этим

операциям относятся доступ к данным, извлечение данных, поиск, отправка данных в другие

системы, резервное копирование и т.д. На рис. 1 представлен общий вид архитектуры

типового насыщенного клиента и показаны компоненты, обычно располагающиеся в каждом

из слоев.