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

Если реализация 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 выделяют для регистрации данных каждого пользователя отдельный файл, и эти файлы могут храниться в разных местах на диске.