Somasegar S., Guthrie Scott. Руководство Microsoft по проектированию архитектуры приложений
Подождите немного. Документ загружается.
Примите решение о том, насколько детализированными должны быть сохраняемые
данные состояния. Например, определите данные состояния, которые относятся ко
всем пользователям приложения, и данные, относящиеся только к определенным
пользователям или ролям.
Рабочий процесс
Некоторые насыщенные клиентские приложения требуют реализации поддержки потока
представления или рабочего процесса для обеспечения многошаговых операций или
элементов UI в стиле мастера. Эти возможности могут быть реализованы с применением
отдельных компонентов или специальных решений, либо можно использовать преимущества
такой технологии, как Windows Workflow Foundation (WF). При проектировании рабочего
процесса руководствуйтесь следующими рекомендациями:
Используйте рабочий процесс в бизнес-компонентах для операций, включающих
многошаговые или длительные процессы. Реализуйте задачи рабочего процесса и
потока представления в отдельных компонентах. Это сокращает количество
зависимостей и упрощает замену компонентов в случае изменения требований.
Для простых рабочих процессов и потоков представления обычно достаточно
собственного кода, основанного на общеизвестных шаблонах, таких Use Case Controller
(Контроллер вариантов использования) и ViewFlow (Поток представления). Для более
сложных случаев используйте подсистему управления рабочим процессом, такую как
WF.
Продумайте стратегию перехвата, управления и отображения ошибок в рабочих
процессах. Также примите решение об обработке частично завершенных задач и о
том, будет ли возможно восстановление и продолжение выполнения задачи после
сбоя либо придется перезапускать процесс.
Более подробно компоненты рабочего процесса рассматриваются в главе 14,
«Проектирование компонентов рабочего процесса».
Вопросы безопасности
Безопасность охватывает широкий диапазон факторов и имеет решающее значение для всех
типов приложений. Проектирование и реализация насыщенных клиентских приложений
должны вестись с обязательным учетом вопросов безопасности, а там где эти приложения
выступают в роли слоя представления для бизнес-приложений, они должны участвовать в
обеспечении безопасности других слоев приложения. Безопасность касается множества
аспектов, включая защиту конфиденциальных данных, аутентификацию и авторизацию
пользователей, защиту от атак злонамеренного кода и пользователей, аудит и
протоколирование событий и действий пользователей. При проектировании стратегии
обеспечения безопасности руководствуйтесь следующими рекомендациями:
Выберите подходящую технологию и подход к аутентификации пользователей,
включая поддержку множества пользователей для одного экземпляра насыщенного
клиентского приложения. Необходимо принять решение о том, как и когда
регистрировать пользователей, должна ли быть реализована поддержка различных
типов пользователей (ролей) с разными правами доступа (например, администраторы
и обычные пользователи), и как регистрировать успешные или неудачные попытки
входа пользователя в систему. Учитывайте требования по аутентификации в
автономном режиме или без подключения, где это необходимо.
Используйте интегрированную аутентификацию Windows (Windows Integrated
Authentication) или интегрированное решение аутентификации, если требуется
обеспечить пользователям возможность доступа к множеству приложений по одному
удостоверению или с использованием одних и тех же учетных данных. Если нет
возможности использовать Windows Integrated Authentication, можно работать с
внешним сервисом, предлагающим интегрированную поддержку аутентификации.
Если нет возможности использовать внешний сервис, используйте систему на базе
сертификатов или создавайте собственное решение для своей организации.
Учтите требования по валидации пользовательского ввода и вывода из таких
источников, как интерфейсы сервисов и других приложений. Возможно, придется
создать собственные механизмы проверки или использовать функции валидации
применяемой технологии. Среда разработки Microsoft Visual Studio® Windows Forms
включает элементы управления валидации. В качестве альтернативы можно
использовать инфраструктуру валидации сторонних производителей, такую как
Enterprise Library Validation Application Block, которая обеспечивает возможности
проверки в UI и бизнес-слое в полном объеме. Независимо от выбранного подхода
следует всегда помнить, что валидация данных должна проводиться при любом
пересечении ими границ доверия.
Продумайте, как будет обеспечиваться защита хранящихся в приложении данных, и
таких ресурсов, как файлы, кэши и документы, используемые приложением. Шифруйте
конфиденциальные данные в случаях, когда есть вероятность их разглашения, и
предусмотрите цифровую подпись для предотвращения повреждения или подделки
данных. В приложениях с самыми высокими требованиями к безопасности шифруйте
часто меняющиеся данные, хранящиеся в памяти. Также не забывайте защищать
конфиденциальные данные, передаваемые по сети или каналу связи.
Продумайте стратегию аудита и протоколирования для приложения и то, какие
данные будут включены в эти журналы. Не забывайте защищать конфиденциальные
данные в журналах с помощью шифрования. Для наиболее важных данных, уязвимых
для повреждения и подделки, предусмотрите цифровые подписи.
Вопросы обработки данных
Серверные приложения могут предоставлять данные приложения через Веб-сервис.
Кэширование этих данных на клиенте позволит улучшить производительность и обеспечит
возможность работы в автономном режиме. Также насыщенные клиентские приложения
могут использовать локальные данные. Данные, используемые насыщенными клиентскими
приложениями можно подразделить на две категории:
Справочные данные только для чтения. Это данные, которые меняются нечасто и
используются клиентом для справочных целей, такие как, например, каталог
продукции. Храните ссылочные данные на клиенте, чтобы сократить объемы данных,
которыми обмениваются клиент и сервер и, таким образом, повысить
производительность приложения, обеспечить возможности работы в автономном
режиме, обеспечить раннюю проверку данных и повысить удобство использования
приложения в общем.
Изменяющиеся данные. Это данные, которые могут изменяться как на клиенте, так и
на сервере. Сложнее всего обеспечивать параллельную обработку таких данных, когда
одновременно многие клиенты могут вносить изменения в одни и те же данные.
Необходимо отслеживать все изменения данных, выполняемые клиентами, и
обрабатывать обновления на сервере, чтобы не допустить возможных конфликтов.
Кэширование данных
Насыщенные клиенты часто кэшируют локально все данные: и справочные данные только для
чтения, и изменяющиеся. Кэширование может улучшить производительность приложения и
обеспечить данные, необходимые для работы в автономном режиме. Для обеспечения
кэширования насыщенные клиентские приложения должны реализовать некоторую
инфраструктуру кэширования, которая может прозрачно реализовывать механизмы
кэширования. Самыми распространенными типами кэширования являются:
Кратковременное кэширование данных. Данные хранятся не постоянно, поэтому
приложение не может выполняться в автономном режиме.
Долгосрочное кэширование данных. Кэширование данных в постоянном хранилище,
таком как изолированное хранилище или локальная файловая система, позволяет
приложению работать без подключения к серверу. Насыщенные клиентские
приложения должны различать данные, которые уже были успешно
синхронизированы на сервере и еще не синхронизированные данные.
Параллельная обработка данных
При одновременном обслуживании множества клиентов возможна ситуация, когда данные на
сервере изменяются до того, как выполняется синхронизация изменений, внесенных другим
клиентом. Это может приводить к нарушению целостности или несогласованности данных.
Поэтому необходимо реализовать механизм, который гарантировал бы соответствующую
обработку любых конфликтов данных при их синхронизации, а также непротиворечивость и
правильность результирующих данных. Самыми распространенными подходами к реализации
параллельной обработки данных являются:
Пессимистическая блокировка. Пессимистическая блокировка используется в случаях,
когда риск конфликтов данных велик. Для предупреждения таких конфликтов данный
тип блокировки позволяет одному клиенту блокировать данные, предотвращая, таким
образом, доступ или изменение этих данных всеми остальными клиентами до тех пор,
пока изменения, вносимые этим клиентом, не будут завершены и подтверждены.
Такая схема также известна как пессимистическая блокировка в автономном режиме.
Оптимистическая блокировка. Оптимистическая блокировка используется в случаях,
когда риск конфликтов данных невелик. При этом типе блокировки клиент не
блокирует данные при обновлении. Для выявления конфликтов данных на сервер
передаются и исходные данные, и измененные. На сервере исходные данные
сравниваются с текущими данными, чтобы выявить, не были ли они обновлены с
момента последнего извлечения. Если нет, изменения принимаются; в противном
случае, формируется исключение конфликта данных. Такая схема также известна как
оптимистическая блокировка в автономном режиме.
ADO.NET DataSet обеспечивает клиентам работу с данными в автономном режиме. DataSets
может отслеживать локальные изменения данных, что упрощает синхронизацию данных с
сервером и разрешение конфликтов данных. DataSets также может использоваться для
объединения данных из разных источников.
Привязка данных
Механизмы привязки данных Windows Forms, WPF и Silverlight поддерживают двустороннюю
привязку, что позволяет связывать структуру данных с компонентом UI, отображать текущие
значения данных пользователю, обеспечивает возможность пользователю редактировать
данные и затем автоматически обновлять их, используя введенные пользователем значения.
Привязка данных может применяться для отображения пользователю данных только для
чтения, позволяет пользователям обновлять данные в UI и просматривать сложные элементы
связанных данных, обеспечивает представления типа мастер/детали и отображение данных из
связанных таблиц, благодаря чему в UI могут отображаться понятные пользователю имена
элементов данных, а не значения ключей строки данных.
Проектированию слоя доступа к данным посвящена глава 8, «Рекомендации по
проектированию слоя доступа к данным». Более подробно проектирование компонентов слоя
доступа к данным для насыщенных клиентских приложений рассматривается в главе 15,
«Проектирование компонентов слоя доступа к данным».
Вопросы автономной работы/работы без постоянного
подключения
Считается, что приложение не имеет постоянного подключения, если оно не имеет
возможности регулярно взаимодействовать с сервисами или данными по сети. Насыщенные
клиентские приложения без постоянного подключения могут выполнять необходимую
обработку без подключения к сетевому ресурсу и обновлять сетевые ресурсы в фоновом
режиме при установлении подключения.
При проектировании приложений без постоянного подключения отдавайте предпочтение
асинхронному взаимодействию и максимально сокращайте или устраняйте сложные
взаимодействия с сетевыми данными и сервисами. Это упростит реализацию механизма
синхронизации, используемого, когда подключение доступно.
Чтобы иметь возможность работы без подключения, приложение должно реализовывать
возможности кэширования данных, которые обеспечивали бы на клиенте все необходимые
для продолжения работы в автономном режиме данные. Также требуется предусмотреть
механизмы, предотвращающие использование устаревших данных. В общем, необходимо
спроектировать механизм передачи данных с промежуточным хранением, при котором
сообщения создаются, хранятся в период отсутствия подключения и, в конце концов,
отправляются в место назначения при установлении подключения. Самой распространенной
реализацией механизма передачи данных с промежуточным хранением является очередь
сообщений.
При проектировании сценария без постоянного подключения возможны два подхода:
Ориентированный на данные. При использовании стратегии с ориентированием на
данные для приложения локально на клиенте устанавливается система управления
реляционной базой данных (relational database management system, RDBMS), и
применяются ее встроенные возможности для переноса локальных изменений данных
на сервер, выполнения процесса синхронизации, выявления и разрешения любых
конфликтов данных.
Сервисно-ориентированный. Приложения, использующие сервисно-ориентированный
подход, хранят данные в сообщениях и, если клиент находится в автономном режиме,
организуют эти сообщения в очереди. Когда подключение восстанавливается,
сообщения, находящиеся в очереди, передаются на сервер для обработки.
Вопросы выбора технологий
Насыщенные клиентские приложения могут быть реализованы с применением нескольких
разных технологий. Следующие рекомендации помогут выбрать соответствующую технологию
реализации и применить соответствующие шаблоны и системные функции для конфигурации
и мониторинга:
Выберите подходящую технологию разработки:
◦ Используйте WFP для приложений, которым необходима полная поддержка
насыщенных мультимедиа и графики.
◦ Используйте Windows Forms, если уже имеете опыт работы c Windows Forms,
либо создаете LOB-приложения, которые не требуют насыщенной
визуализации и должны выполняться с минимальными требованиями к
оборудованию.
◦ Используйте XBAP для приложений, которые будут загружаться с Веб-сервера и
затем выполняться в браузере.
◦ Используйте OBA для, преимущественно, основанных на документах
приложений, либо приложений, которые будут использоваться для составления
отчетов.
Ознакомьтесь с предложениями patterns & practices, которые могут быть полезны
при проектировании и реализации приложения:
◦ Используйте Smart Client Software Factory, если решили работать с Windows
Forms и проектируете составные интерфейсы.
◦ Используйте Composite Client Application Guidance
55
, если решили работать с
WPF и/или Silverlight и желаете создавать модульные приложения, которые
обычно включают множество окон, насыщенные гибкие сценарии
взаимодействия с пользователем и визуализации данных, а также
определяемое ролью поведение.
◦ Используйте Enterprise Library для реализации решений сквозной
функциональности, таких как обработка исключений, кэширование и
валидация.
Если решено использовать WPF:
◦ Реализуйте шаблон Presentation Model или View Model, чтобы обеспечить
возможность модульного тестирования логики UI и упростить изменение
стилевого оформления приложения.
◦ WPF позволяет подключать дополнительное поведение к существующим
реализациям элементов управления. Этот подход является более
предпочтительным, чем создание подклассов для элементов управления.
Если требуется обеспечить поддержку удаленного администрирования и
мониторинга:
◦ Реализуйте переопределения групповой политики (Group Policy) для
конфигурации приложения. Это необходимо для обеспечения соответствия
требованиям программы Certified for Windows (Сертифицировано для
Windows).
◦ Используйте такие технологии, как SNMP и WMI, чтобы обеспечить
предоставление сведений об исключениях и состоянии работоспособности.
Вопросы развертывания
Существует несколько вариантов развертывания насыщенных клиентских приложений. Можно
создать самодостаточное приложение, для которого вся логика приложения, включая данные,
развертывается на клиентском компьютере. Другой вариант – схема клиент/сервер, при
которой логика приложения развертывается на клиенте, а данные – на уровне базы данных.
Наконец, существует несколько n-уровневых вариантов развертывания, при которых логика
приложения размещается на одном или нескольких серверах приложений.
Самодостаточное приложение
Рис. 2 иллюстрирует схему развертывания самодостаточного приложения, когда вся логика
приложения и данные размещаются на клиенте.
55
Также известный как Prism (прим. научного редактора)
Рис. 34
Развертывание насыщенного клиентского приложения как самодостаточного приложения
Развертывание по схеме клиент/сервер
При развертывании по схеме клиент/сервер вся логика приложения располагается на клиенте,
и данные размещаются на сервере базы данных, как показано на рис. 3.
Рис. 35
Развертывание насыщенного клиентского приложения по схеме клиент/сервер
N-уровневое развертывание
При n-уровневом развертывании на клиенте могут размещаться логика представления и
бизнес-логика или только логика представления. Рис. 4 иллюстрирует первый вариант.
Рис. 36
N-уровневое развертывание, при котором бизнес-слой размещается на клиентском уровне
Рис. 5 иллюстрирует вариант, когда бизнес-логика и логика доступа к данным располагаются
на сервере приложений.
Рис. 37
N- уровневое развертывание, при котором бизнес-слой размещается на уровне приложений
Более подробно стратегии развертывания рассматриваются в главе 19, «Физические уровни и
развертывание».
Технологии развертывания
Существует несколько вариантов физического развертывания насыщенного клиентского
приложения, каждый из которых обладает определенными преимуществами и недостатками.
Необходимо внимательно рассмотреть все варианты, чтобы сделать правильный выбор,
удовлетворяющий требованиям целевых инфраструктур, в которых предполагается выполнять
приложение. Предлагаются такие варианты развертывания:
Развертывание ClickOnce. Этот подход требует минимального участия пользователя,
небольших усилий для разработчика и обеспечивает автоматизированное обновление.
Тем не менее, он может использоваться для развертывания только отдельного
решения, не являющегося частью большего решения. Этот подход нельзя применять
для развертывания дополнительных файлов или разделов реестра; он не обеспечивает
пользователю возможность конфигурации установки; и не позволяет создавать
фирменный стиль установщика.
Развертывание XCOPY. Если нет необходимости в установке параметров реестра или
регистрации компонентов, исполняемый файл можно просто копировать на жесткий
диск клиентского компьютера.
Пакет Установщик Windows (.MSI). Это полная программа настройки, которая может
устанавливать компоненты, ресурсы, параметры реестра и другие артефакты,
необходимые приложению. Для установки самих пакетов MSI пользователь должен
иметь права доступа администратора. Существуют решения для распространения
приложений в среде предприятия, такие как Microsoft System Center Configuration
Manager.
Пакет XBAP. Приложение загружается через браузер и выполняется в ограниченной
безопасной среде на компьютере. Обновления могут передаваться на клиент
автоматически.
Шаблоны проектирования
Основные шаблоны проектирования организованы по категориям, таким как Сетевое
взаимодействие, Композиция, Управление конфигурацией, Управление исключениями,
Представление, Управление состоянием и Рабочий процесс, и представлены в следующей
таблице. Рассмотрите возможности применения этих шаблонов при принятии проектных
решений для каждой из категорий.
Категория
Шаблоны
Сетевое
взаимодействие
Asynchronous Callback. Реализует длительные задачи в отдельном
потоке, выполняющемся в фоновом режиме, и обеспечивает потоку
функцию для обратного вызова по завершении выполнения задачи.
Gateway (Шлюз). Обеспечивает доступ к внешней системе через общий
абстрактный интерфейс взаимодействия так, что потребителям нет
необходимости понимать внешний интерфейс системы.
Service Locator (Локатор сервиса). Централизует поиск
распределенных объектов сервисов, обеспечивает централизованную
точку управления и выступает в роли кэша, благодаря которому
сокращается количество лишних операций поиска.
Service Agent and Proxy (Агент и прокси сервиса). Реализует
компонент, который может использоваться приложением для доступа к
компоненту/сервису, и при этом приложение даже не будет знать, что
обращается не к фактическому компоненту/сервису. Этот компонент
передает вызовы приложения в удаленный компонент/сервис и
возвращает результат приложению. Прокси абстрагирует детали
взаимодействия с другими удаленными компонентами, как правило, при
использовании сервисов ASMX или WCF.
Service Interface. Программный интерфейс, который может
использоваться другими системами для взаимодействия с сервисом.
Композиция
Composite View. Сочетает отдельные представления в композитное
представление.
Template View. Реализует представление общего шаблона и создает
представления на базе этого шаблонного представления.
Two-Step View. Преобразует модель данных в логическое представление
без какого-либо специального форматирования и затем преобразует это
логическое представление, добавляя необходимое форматирование.
View Helper (Вспомогательный объект представления). Делегирует
ответственность за обработку бизнес-данных вспомогательным классам.
Управление
конфигурацией
Provider. Реализует компонент, который предоставляет API,
отличающийся от клиентского API, обеспечивая возможность
подключения любой специальной реализации.
Управление
исключениями
Exception Shielding. При возникновении исключения предотвращает
предоставление сервисом данных о его внутренней реализации.
Представление
Application Controller. Объект, содержащий всю логику приложения и
используемый другими Контроллерами, работающими с Моделью и
отображающими соответствующее Представление.
Model-View-Presenter. Разделяет обработку запроса на три отдельные
роли, где Представление отвечает за обработку пользовательского
ввода, Модель – за данные приложения и бизнес-логику, и Презентатора
– за логику представления и координирование взаимодействия между
Представлением и Моделью.
Model-View-ViewModel. Разновидность шаблона Model-View-Controller
(MVC), приспособленная для современных платформ разработки UI, на
которых созданием представления (View) занимаются, главным образом,
дизайнеры, а не обычные разработчики
Presentation Model (Модель презентации). Распределяет обязанности
по визуальному отображению пользовательского интерфейса,
реализации состояния представления и поведения между разными
классами, которые названы представление и модель презентации,
соответственно. Класс представления управляет элементами управления
пользовательского интерфейса и инкапсулирует визуальное состояние
или поведение, характерное для UI. Класс модели презентации
инкапсулирует поведение представления и выступает в роли фасада для
базовой модели.
Управление состоянием
Context Object (Объект контекста). Объект, используемый для
управления текущим контекстом обработки.
Рабочий процесс
View Flow (Поток представления). Управляет переходами от одного
представления к другому на основании состояния приложения или среды,
а также условий и ограничений, необходимых для правильной работы
приложений.
Work Flow (Рабочий процесс). Управляет предопределенным потоком
управления в сложном процессно-ориентированном приложении,
обеспечивая при этом возможность динамического изменения хода
выполнения через решения и структуры ветвления, которые могут
изменять маршрутизацию запросов.
Более подробно шаблоны Template View, Transform View и Two-Step View рассматриваются в
книге Мартина Фаулера «Архитектура корпоративных приложений». Addison-Wesley, 2002.
Или по адресу http://martinfowler.com/eaaCatalog.
Более подробно шаблон Provider рассматривается в материале «Provider Model Design Pattern
and Specification, Part I» по адресу http://msdn.microsoft.com/en-us/library/ms998421.aspx.
Более подробно шаблон Asynchronous Callback рассматривается в статье «Creating a Simplified
Asynchronous Call Pattern for Windows Forms Applications» по адресу
http://msdn.microsoft.com/en-us/library/ms996483.aspx.
Более подробно шаблон Service Interface рассматривается в статье «Service Interface» по адресу
http://msdn.microsoft.com/en-us/library/ms998421.aspx.
Более подробно шаблон Exception Shielding рассматривается в статье «Useful Patterns for
Services» по адресу http://msdn.microsoft.com/en-us/library/cc304800.aspx.
Более подробно шаблон Composite View рассматривается в статье «Patterns in the Composite
Application Library» по адресу http://msdn.microsoft.com/en-us/library/dd458924.aspx.
Более подробно шаблон Presentation Model рассматривается в статье «Presentation Model»
(Модель презентации) по адресу http://msdn.microsoft.com/en-us/library/dd458863.aspx.