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

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

 Выработайте стратегию передачи журналов клиента на сервер для обработки. При

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

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

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

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

пользователей.

 При использовании изолированного хранилища для протоколирования

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

запроса пользователю об увеличении объема хранилища в случае необходимости.

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

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

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

Реализации RIA обеспечивают намного более насыщенный интерфейс пользователя и лучшую

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

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

возможности платформы RIA могут быть недоступны в автономном проигрывателе

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

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

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

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

использовать адаптивную потоковую передачу в сочетании с RIA-клиентами, это

позволит корректно и плавно обрабатывать проблемы, возникающие из-за

изменяющейся полосы пропускания.

 Для повышения производительности позиционируйте объекты мультимедиа с

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

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

встроенные средства обработки векторной графики.

 Для особо насыщенного графикой приложения выясните, обеспечивает ли

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

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

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

 Принимайте во внимание размер областей отрисовки. Перерисовывайте только те

части области, которые на самом деле меняются. Сокращайте области перекрытия,

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

методы профилирования и отладки (например, параметр «EnableRedrawRegions =

true» в Silverlight) для выявления перерисованных областей. Обратите внимание,

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

каждого пиксела области. Безоконные прозрачные элементы управления могут

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

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

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

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

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

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

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

 Если RIA должно устанавливаться на мобильном клиенте, выясните, доступна ли

реализация подключаемого модуля RIA для устройства, которое предполагается

поддерживать. Также примите во внимание, что функциональность подключаемого

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

немобильными платформами.

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

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

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

мобильных устройств. RIA-приложения работают на мобильных устройствах, но

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

обеспечить корректное отображение UI на экранах разных размеров при

проектировании для Windows Mobile.

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

главе 24, «Проектирование мобильных приложений».

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

Одно из основных преимуществ RIA – портируемость компилированного кода между разными

браузерами, операционными системами и платформами. Кроме того, использование одного и

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

обслуживание, обеспечивая при этом независимость от платформы. При проектировании с

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

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

«однажды написанное выполнялось везде», но будьте готовы создавать различные

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

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

 Выбирая между RIA и Веб-приложением, не забывайте, что из-за различий

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

ASP.NET и JavaScript. В случае с RIA-приложением вопросами совместимости с

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

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

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

 Если RIA планируется выполнять на множестве платформ, не используйте

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

Integrated Authentication. Основывайте решение на портируемых процедурах и

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

 При создании насыщенных клиентских или RIA-приложений обратите внимание на

языки и среды разработки, такие как Composite Client Application Guidance группы

patterns & practices, предлагающие решения, подходящие для обеих платформ.

Подробнее эти вопросы рассматриваются в статье «Composite Client Application

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

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

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

всего они работают при наличии всего одного центрального интерфейса. Для

многостраничных приложений требуются механизмы связывания страниц. При

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

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

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

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

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

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

ошибок в коде. Также это может обеспечить автоматическую синхронизацию

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

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

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

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

приложения.

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

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

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

навигации, как на обычной Веб-странице.

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

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

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

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

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

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

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

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

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

 Определите, какие данные состояния должно сохранять приложение, оцените

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

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

данных.

 Чтобы сохранить состояние между сеансами, храните данные состояния на клиенте

в изолированном хранилище. Состояние, необходимое для функционирования

приложения, всегда должно сохраняться на сервере. Это также обеспечивает

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

компьютера.

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

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

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

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

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

Валидация

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

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

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

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

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

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

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

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

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

со всех источников, таких как строки запроса, cookies и элементы управления HTML.

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

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

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

их.

 Храните правила валидации клиента в изолированном хранилище. Для правил,

требующих доступа к ресурсам сервера, продумайте, не будет ли более

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

 При наличии на стороне клиента большого объема кода валидации, который может

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

модуле. Это упростит его замену без необходимости повторной загрузки всего RIA-

приложения.

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

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

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

типов приложений. Проектирование и реализация насыщенных Интернет-приложений

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

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

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

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

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

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

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

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

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

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

должна ли быть реализована поддержка различных типов пользователей (ролей) с

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

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

 Используйте интегрированную аутентификацию Windows (Windows Integrated

Authentication), механизм единой регистрации (single sign-on, SSO) или

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

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

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

Windows Integrated Authentication, можно применить внешний сервис, предлагающий

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

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

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

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

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

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

предлагаемые применяемой технологией UI.

 Продумайте стратегию аудита и протоколирования для приложения и то, какие

данные будут регистрироваться. Не забывайте защищать конфиденциальные данные в

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

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

Вопросы обработки данных

Как правило, доступ к данным приложения осуществляется через сетевые сервисы. Кэшируйте

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

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

 Справочные данные только для чтения. Это данные, которые меняются нечасто и

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

продукции. Храните ссылочные данные на клиенте, чтобы сократить объемы данных,

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

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

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

приложения в общем.

 Изменяющиеся данные. Это данные, которые могут изменяться как на клиенте, так и

на сервере. Сложнее всего в насыщенных Интернет-приложениях обеспечивать

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

вносить изменения в одни и те же данные. Необходимо отслеживать все изменения

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

допустить возможных конфликтов.

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

Далее приводится руководство по применению Silverlight и Microsoft Windows Communication

Foundation (WCF). На момент написания данного документа были выпущены версии WCF 3.5 и

Silverlight 3.0. Данные рекомендации помогут при выборе и реализации соответствующей

технологии.

Версии и целевые платформы

 На момент выхода данного руководства Silverlight for Mobile был объявлен и

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

 На текущий момент посредством подключаемого модуля технологию Silverlight

поддерживают браузеры Safari, Firefox и Microsoft Internet Explorer. Через эти

браузеры Silverlight поддерживает Mac и Windows. В 2008 году было объявлено о

поддержке для Windows Mobile. Реализация Silverlight с открытым исходным кодом

под названием Moonlight обеспечивает поддержку систем Linux и Unix/X11.

 Silverlight поддерживает языки разработки C#, Iron Python, Iron Ruby и Visual Basic®

.NET. Большая часть XAML-кода также может выполняться как на WPF-, так и на

Silverlight-хостах.

 В Silverlight 2.0 необходимо реализовывать собственный код валидации ввода и

данных. Silverlight 3.0 поддерживает валидацию на основании исключений через

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

валидации доступны в текущей версии.

Безопасность

 Криптографические API .NET доступны в Silverlight и должны применяться при

хранении и передаче на сервер конфиденциальных данных, если они еще не

зашифрованы с использованием другого механизма шифрования.

 Для каждого зарегистрированного пользователя Silverlight создает отдельный файл

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

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

извлечением логики программы.

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

 Silverlight поддерживает только асинхронное взаимодействие с Веб-сервисами.

 Silverlight поддерживает только основные HTTP-привязки. WCF в .NET 3.5

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

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

крайней мере, безопасность на транспортном уровне.

 Silverlight поддерживает два формата файлов для вызова сервисов, которые

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

использовать либо специальный файл для Silverlight, ClientAccessPolicy.xml, либо

файл CrossDomain.xml, совместимый с Adobe Flash. Разместите файл в корневом

каталоге сервиса(-ов), к которому(-ым) должен выполнять доступ Silverlight-клиент.

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

приложении ADO.NET Data Services.

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

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

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

Элементы управления

 Silverlight включает элементы управления, специально спроектированные для него.

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

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

 Используйте безоконный режим работы Silverlight, если желаете размещать

видимое HTML-содержимое и элементы управления поверх Silverlight-приложения.

 Silverlight позволяет вводить дополнительное поведение в существующие

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

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

 Silverlight выполняет сглаживание всех компонентов UI, поэтому учтите

рекомендации по привязке элементов UI к целочисленным значениям пикселов.

Хранение

 В качестве локального механизма хранения для Silverlight используется

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

размер – 1 МБ. Максимальный размер хранилища не ограничен, но в Silverlight

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

приложения.

Дополнительную информацию можно найти также в материале «Contrasting Silverlight and

WPF» (Сравнение Silverlight и WPF) по адресу http://msdn.microsoft.com/en-

us/library/dd458872.aspx.

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

Реализации RIA с точки зрения развертывания и удобства обслуживания обеспечивают во

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

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

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

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

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

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

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

браузера для RIA не установлен.

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

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

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

отдельности. Это позволит без труда заменять их, и пользователю при этом не

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

 Создавайте версии компонентов.

Установка подключаемого модуля RIA

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

он еще не установлен:

 Интранет. По возможности используйте программное обеспечение

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

Active Directory® для предварительной установки подключаемого модуля на

каждый компьютер организации. Альтернативный вариант – применение

клиентского компонента Центра обновления Windows, где Silverlight является

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

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

Администратора на клиентском компьютере.

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

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

последней версии подключаемого модуля. Для пользователей Windows Центр

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

компонент.

 Обновления подключаемого модуля. Как правило, обновления подключаемого

модуля разрабатываются с учетом обратной совместимости. Создавая свое

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

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

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

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

тестирования в нем своего приложения. В Интернет-сценариях учитывайте то, что

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

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

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

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

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

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

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

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

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

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

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

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

рис. 2.

Рис. 39

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

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

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

RIA на клиенты.

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

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

 Если в приложении используются сокеты или WCF и не используется порт 80,

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

которые обычно блокируют другие порты.

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

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

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

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

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

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

способность. На рис. 3 представлен сценарий с балансировкой нагрузки.

Рис. 40

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

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

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

 Избегайте привязки к конкретному серверу, т.е. ситуации, когда все запросы от

определенного клиента обрабатываются одним и тем же сервером. Чаще всего это

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

либо хранилищ состояния сеансов в процессе или локальных хранилищ.

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

компоненты без сохранения состояния.

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

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

Веб-ферма

Если к RIA-приложению предъявляются довольно высокие требования по обработке бизнес-

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

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

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

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

использоваться решения с балансировкой нагрузки или кластеризацией. Руководствуйтесь

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

 Используйте кластеризацию для снижения влияния сбоев оборудования.

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

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