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

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

Реализации RIA копируют или переносят логику представления на клиент, поэтому наиболее вероятным сценарием их развертывания является распределенная архитектура. При распределенном развертывании RIA логика представления располагается на клиенте; бизнесслой может находиться на клиенте, на сервере или распределяться между клиентом и сервером; и слой доступа к данным размещается на Веб-сервере или сервере приложений. Как правило, часть бизнес-логики (и даже, возможно, некоторая логика доступа к данным) переносится на клиент для повышения производительности. В этом случае бизнес-слой и слой доступа к данным распределяются между клиентом и сервером приложений, как показано на рис. 2.

Рис. 39

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

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

Для большого приложения учтите временные затраты при загрузке компонентов RIA на клиенты.

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

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

Используйте файл crossdomain.xml, чтобы обеспечить RIA-клиентам возможность доступа к другим доменам в случае необходимости.

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

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

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

Рис. 40

Развертывание RIA с балансировкой нагрузки

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

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

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

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

Веб-ферма

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

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

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

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

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

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

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

Категория	Шаблоны
Слои	Service Layer (Слой сервисов). Архитектурный шаблон, в котором интерфейс
	сервисов и реализация вынесены в отдельный слой.
Сетевое	Asynchronous Callback. Выполняет длительные задачи в отдельном потоке,
взаимодействие	выполняющемся в фоновом режиме, и обеспечивает потоку функцию для
	обратного вызова по завершении выполнения задачи.
	Command. Инкапсулирует обработку запроса в отдельный командный объект с
	обычным интерфейсом выполнения.
Композиция	Composite View. Сочетает отдельные представления в композитное
	представление.
	Inversion of Control. Заполняет все зависимости объектов от других объектов
	или компонентов, которые должны быть выполнены, прежде чем приложение
	сможет использовать объект.
Представление	Application Controller. Объект, содержащий всю логику выполнения и
	используемый другими Контроллерами, работающими с Моделью и
	отображающими соответствующее Представление.
	Supervising Presenter (Наблюдающий презентатор). Разделяет дизайн
	презентации на три разные роли, где Представление отвечает за обработку
	пользовательского ввода и обменивается данными с компонентом Модели,
	который инкапсулирует бизнес-данные. Объект Презентатор реализует логику
	представления и координирует взаимодействия между Представлением и
	Моделью.
	Presentation Model. Разновидность шаблона Model-View-Presenter (MVP),
	предназначенная для современных платформ разработки UI, где созданием
	Представления занимается дизайнер, а не разработчик.

Более подробно шаблон Composite View рассматривается в статье «Patterns in the Composite Application Library» at http://msdn.microsoft.com/en-us/library/dd458924.aspx.

Более подробно шаблоны Model-View-Controller (MVC) и Application Controller

рассматриваются в книге Мартина Фаулера «Архитектура корпоративных приложений».

Addison-Wesley, 2002. Или по адресу http://martinfowler.com/eaaCatalog.

Более подробно шаблон Command рассматривается в главе 5, «Поведенческие шаблоны» книги Эрика Гамма, Ричарда Хельма, Ральфа Джонсона и Джона Влиссидса «Приемы объектно-ориентированного проектирования. Паттерны проектирования». Питер, 2006.

Более подробно шаблон Asynchronous Callback рассматривается в статье «Creating a Simplified Asynchronous Call Pattern for Windows Forms Applications» по адресу http://msdn.microsoft.com/en-us/library/ms996483.aspx.

Более подробно шаблон Service Layer рассматривается в статье «P of EAA: Service Layer» (Архитектура корпоративных программных приложений: слой сервисов) по адресу http://www.martinfowler.com/eaaCatalog/serviceLayer.html.

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

Электронная версия списка используемых источников доступна по адресу http://www.microsoft.com/architectureguide.

Информацию по Silverlight можно найти на официальном Веб-сайте Silverlight по адресу http://silverlight.net/default.aspx.

Об использовании WCF с Silverlight рассказывают статьи «How to: Build a Duplex Service» (Как: создать дуплексный сервис) по адресу http://msdn.microsoft.com/enus/library/cc645027(VS.95).aspx и «How to: Access a Duplex Service with the Channel Model» (Как: организовать доступ к дуплексному сервису с использованием модели канала) по адресу http://msdn.microsoft.com/en-us/library/cc645028(VS.95).aspx.

Блоги по Silverlight: блог Бреда Абрамса (Brad Abrams) можно найти по адресу http://blogs.msdn.com/brada/ и блог Скотта Гатри (Scott Guthrie) можно найти по адресу http://weblogs.asp.net/Scottgu/.