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

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

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

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

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

 Проектированию составных приложений посвящено руководство «Composite Client

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

 Более подробно проектирование насыщенных клиентских приложений и клиентских

приложений с расширенной логикой рассматривается в руководстве «Smart Client

Architecture and Design Guide» (Руководство по архитектуре и дизайну клиентских

приложений с расширенной логикой) по адресу http://msdn.microsoft.com/en-

us/library/ms998506.aspx.

 Архитектуры кэширования обсуждаются в статье «Caching Architecture Guide for .NET

Framework Applications» по адресу http://msdn.microsoft.com/en-

us/library/ms978498.aspx.

 Сценарии и вопросы развертывания подробно рассматриваются в статье «Deploying

.NET Framework-based Applications» по адресу http://msdn.microsoft.com/en-

us/library/ms954585.aspx.

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

Интернет-приложений

Обзор

В данной главе рассматриваются основные сценарии использования Насыщенных Интернет-

приложений (Rich Internet Applications, RIA), их компоненты и важные аспекты

проектирования. Даются рекомендации по обеспечению производительности, безопасности и

развертыванию, а также основные шаблоны и технологии проектирования RIA.

RIA поддерживают насыщенные графические элементы и сценарии с применением потокового

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

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

как Microsoft® Silverlight®, в отличие от расширений, использующих код браузера, таких как

Asynchronous JavaScript и XML (AJAX). Типовая реализация RIA использует Веб-инфраструктуру в

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

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

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

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

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

сервер. На рис. 1 представлена типовая структура реализации RIA.

Рис. 38

Архитектура типовой реализации RIA. Пунктиром обозначены необязательные

компоненты.

Типовое насыщенное Интернет-приложение включает три слоя: слой представления, бизнес-

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

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

сущностей; и слой доступа к данным – компоненты доступа к данным и агентов сервисов.

В RIA часть бизнес-процессов и даже код доступа к данным часто переносятся на клиент.

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

функциональность бизнес-слоя и слоя доступа к данным. На рис. 1 показано, как некоторые

бизнес-процессы обычно реализовываются на клиенте.

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

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

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

Следовательно, дизайн и реализация RIA могут быть очень разнообразными. Тем не менее,

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

представления и его взаимодействия с сервисами на сервере. Многие из них основываются на

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

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

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

использования.

Многослойному дизайну посвящена глава 5, «Рекомендации по проектированию

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

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

Общие принципы проектирования

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

учтены при проектировании RIA, и помогут обеспечить эффективную работу приложения в

общих для RIA сценариях и соответствие выдвигаемым требованиям:

 Выбирайте RIA, исходя из предполагаемой аудитории, насыщенного интерфейса

и простоты развертывания. Создавайте RIA, если целевая аудитория использует

браузер, поддерживающий RIA. Если часть целевой аудитории работает с

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

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

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

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

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

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

приложение. Реализации RIA прекрасно подходят для Веб-сценариев, в которых

требования, предъявляемые к визуализации, превышают возможности,

обеспечиваемые базовым HTML. RIA обеспечивают более устойчивое поведение и

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

сравнению с Веб-приложениями, использующими расширенные функции и код.

Реализации RIA также идеально подходят для приложений, работающих с

потоковыми мультимедиа. Они не так хороши для сверхсложных многостраничных

UI.

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

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

обработка RIA и также взаимодействие с другими сетевыми сервисами (для

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

 Используйте вычислительные мощности клиента. RIA выполняются на клиентском

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

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

это позволит улучшить взаимодействие с пользователем. Однако особо важные

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

может быть сфальсифицирована.

 Обеспечивайте выполнение в безопасной программной среде браузера.

Реализации RIA обладают более высокой безопасностью по умолчанию, поэтому не

имеют доступа ко всем ресурсам компьютера, таким как камеры и аппаратное

ускорение видео. Доступ к локальной файловой системе ограничен. Локальное

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

 Определитесь с тем, насколько сложным будет UI. Продумайте, насколько

сложным будет создаваемый UI. Реализации RIA лучше работают при

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

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

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

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

запуска всего процесса. Для многостраничных UI применяйте методы внешнего

связывания. Также управляйте унифицированным указателем ресурса (Uniform

Resource Locator, URL), историей и кнопками назад/вперед браузера во избежание

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

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

времени отклика приложения. Проанализируйте общие сценарии приложений и

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

кэшировании данных или переносе бизнес-логики на клиент. Чтобы сократить

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

загружаемые компоненты.

 Предусмотрите ситуацию отсутствия установленного подключаемого модуля.

Реализации RIA требуют наличия подключаемого модуля браузера, поэтому

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

выполнения приложения. Учтите то, имеют ли ваши клиенты доступ к

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

устанавливать. Подумайте над тем, насколько детально будете контролировать

процесс установки. Предусмотрите ситуацию, когда пользователи не могут

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

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

Веб-интерфейса.

Кроме приведенных выше рекомендаций по реализаций RIA, руководствуйтесь и более

общими советами по проектированию насыщенных клиентских приложений (включая

мобильные насыщенные клиенты). К общим рекомендациям относятся отделение логики

представления от реализации интерфейса, определение задач представления и потоков

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

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

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

других слоев и сокращение числа обращений к сети при доступе к удаленным слоям. Более

подробно эти вопросы рассматриваются в главе 22, «Проектирование насыщенных клиентских

приложений».

Специальные вопросы проектирования

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

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

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

вызывают затруднения:

 Бизнес-слой

 Кэширование

 Сетевое взаимодействие

 Композиция

 Доступ к данным

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

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

 Мультимедиа и графика

 Приложения для мобильных устройств

 Портируемость

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

 Управление состоянием

 Валидация

Бизнес-слой

В большинстве сценариев RIA-приложения выполняют доступ к данным или сведениям,

расположенным вне приложения. Природа этих данных может быть различной, но, по всей

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

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

размещать на клиенте. При проектировании взаимодействия бизнес-слоя и слоя сервисов

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

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

приложение. Бизнес-слой, располагающийся на клиенте, должен

взаимодействовать с интерфейсами сервисов посредством агента сервиса. Агенты

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

описание сервиса.

 Если бизнес-логика не работает с конфиденциальными данными, можно

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

и время отклика приложения. Если все-таки конфиденциальные данные

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

 Продумайте, как клиент будет получать данные, необходимые для выполнения

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

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

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

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

 Если реализация RIA допускает возможность создания экземпляра без UI, ее можно

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

структурированных, мощных или знакомых языков программирования (таких как

C#), вместо менее гибких поддерживаемых браузерами языков.

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

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

реализация RIA допускает это). Это сократит различия между реализациями и

обеспечит единообразие при обработке правил. Модели предметной области,

которые могут существовать и на стороне сервера, и на стороне клиента, должны

быть максимально подобными.

 По соображениям безопасности не размещайте особо важную незашифрованную

бизнес-логику на клиенте. Код в загруженных XAP-файлах может быть без труда

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

доступ к ней с помощью Веб-сервисов.

Более подробно реализация бизнес-слоя рассматривается в главе 7, «Рекомендации по

проектированию бизнес-слоя».

Кэширование

Как правило, реализации RIA используют обычный механизм кэширования браузера.

Разумный подход к кэшированию ресурсов обеспечит повышение производительности

приложения. При проектировании стратегии кэширования руководствуйтесь следующими

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

 Разделение больших клиентских приложений на меньшие отдельно загружаемые

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

улучшения производительности и сокращения числа обращений к сети. По

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

элементов при запуске. Используйте установку, обновления и пользовательские

сценарии для разделения приложения и его модульной загрузки. Например,

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

дополнительную функциональность в фоновом режиме. С помощью событий

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

понадобиться.

 Позвольте браузеру кэшировать объекты, изменение которых в течение сеанса

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

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

сеансами.

 Во избежание непредвиденных исключений обеспечьте достаточно большое

изолированное хранилище данных. Объем хранилища не увеличивается

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

Более подробно проектирование стратегии кэширования рассматривается в главе 17,

«Сквозная функциональность».

Сетевое взаимодействие

Реализации RIA должны использовать асинхронную модель вызовов для сервисов, это

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

используемых протоколов и эффективности сервисов должны быть учтены при

проектировании. Если реализация RIA допускает это, используйте отдельный поток для

операций, выполняющихся в фоновом режиме. При проектировании стратегии сетевого

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

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

асинхронное выполнение, это позволит избежать блокировки потока UI.

 Обеспечьте, чтобы RIA и вызываемые им сервисы использовали совместимые

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

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

поддерживаемые реализацией RIA.

 Для защиты каналов связи используйте безопасные Интернет-протоколы (Internet

Protocol Security, IPSec) и протокол безопасных соединений (Secure Sockets Layer,

SSL), для защиты данных – шифрование, и цифровые подписи для выявления

повреждения или подделки данных.

 Для обеспечения доступа RIA-клиента к другим серверам/доменам, не тем, с

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

 Используйте механизм двусторонней передачи с Windows Communication

Foundation (WCF) для выталкивания данных на клиент, если опрос клиента

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

сервер, если такой вариант намного эффективнее, чем использование сервисов,

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

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

межсетевые экраны и маршрутизаторы могут блокировать некоторые порты и

протоколы. Более подробную информацию по этим вопросам можно найти в

материалах, приведенных в разделе «Дополнительные источники» в конце этой

главы.

Более подробно проектирование сервисов рассматривается в главе 25, «Проектирование

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

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

Композиция

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

приложения, которые не требуют повторной реализации или повторного развертывания всего

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

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

новых модулей или новых версий модулей; упростит настройку или персонализацию

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

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

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

 Продумайте, подходит ли композиция для вашего сценария, и, если подходит,

выберите наиболее подходящие шаблоны модели композиции. Композиция

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

сценариях с минимальными или вообще без изменений. Однако избегайте

дизайнов, вводящих зависимости, что потребует частого повторного развертывания

приложения.

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

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

необходимо обеспечить пользователю возможность расширять или настраивать

приложение.

Доступ к данным

Реализации RIA запрашивают данные с Веб-сервера через сервисы так же, как AJAX-клиент. На

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

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

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

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

серверу и обеспечить UI с меньшим временем отклика.

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

передаваемых по сети данных.

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

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

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

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

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

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

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

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

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

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

координирование исключений между кодом клиента и сервера. При проектировании

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

 Проектируйте как синхронные, так и асинхронные исключения. Используйте блоки

try/catch для перехватывания исключений в синхронном коде. Обработку

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

специально предусмотренный для таких исключений; например, в Silverlight таким

обработчиком является OnError.

 Выработайте стратегию кэширования и обработки необрабатываемых исключений.

Необрабатываемые исключения в RIA передаются в браузер. Это позволяет

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

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

сообщение об ошибке. Останавливайте программу, если продолжение выполнения

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

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

стабильном состоянии.

 Перехватывайте только те внутренние исключения, которые можете обработать.

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

возникать при попытке преобразования значений null. Не используйте исключения

для управления бизнес-логикой.

 Правильно проектируйте стратегию распространения исключений. Например,

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

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

следующий уровень.

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

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

конфиденциальных данных.

Более подробно проектирование стратегии управления исключениями рассматривается в

главе 17, «Сквозная функциональность».

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

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

довольно сложную задачу в RIA. Например, приложения Silverlight не имеют доступа к

клиентской файловой системе, клиентская и серверная части выполняются асинхронно.

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

файлы журнала клиента с файлами журнала сервера. При проектировании стратегии

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

 Рассмотрите ограничения компонента протоколирования в реализации RIA.

Некоторые реализации RIA выделяют для регистрации данных каждого

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

диске.