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

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

Рис. 33

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

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

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

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

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

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

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

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

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

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

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

такого приложения является приложение для ввода данных, передающее все данные на

сервер для обработки и хранения.

И наоборот, насыщенные клиентские приложения могут быть очень сложными

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

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

данных. Примером такого приложения является ПО на базе Microsoft Excel®, которое

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

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

данных. Такие насыщенные клиенты имеют собственные бизнес-слои и слои доступа к

данным. Рекомендации по проектированию бизнес-слоев и слоев доступа к данным в таких

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

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

Целью архитектора ПО при проектировании насыщенного клиентского приложения является

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

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

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

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

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

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

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

приложению. К таким технологиям относятся Windows Forms, WPF, XAML Browser

Applications (XBAP) и OBA.

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

шаблоны проектирования, как Presentation Model и Supervising Presenter (или

Supervising Controller), которые отделяют формирование визуального отображения UI

от логики UI. Использование отдельных компонентов в приложении сокращает

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

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

 Выясните задачи представления и потоки представления. Это поможет

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

мастера.

 Спроектируйте подходящий и удобный интерфейс. Для обеспечения максимальной

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

компоновка, навигация, выбор элементов управления и локализация.

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

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

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

размещаемые в слое доступа к данным.

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

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

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

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

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

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

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

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

описаниями интерфейсов, абстрактные базовые классы или обмен сообщениями.

Например, реализация шаблонов Dependency Injection и Inversion of Control может

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

слоями.

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

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

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

отвечает».

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

проектированию бизнес-слоя». Проектированию слоя доступа к данным посвящена глава 8,

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

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

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

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

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

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

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

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

 Композиция

 Управление конфигурацией

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

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

 Удобство и простота обслуживания

 Слой представления

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

 Рабочий процесс

Бизнес-слой

Типовой тонкий насыщенный клиент выступает в роли интерфейса бизнес-системы, а бизнес-

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

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

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

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

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

приложением. Если приложение будет работать с удаленными сервисами,

импортируйте описания интерфейсов и напишите код доступа к функциям этих

сервисов с использованием интерфейсов. Это поможет уменьшить связанность между

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

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

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

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

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

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

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

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

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

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

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

слоя».

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

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

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

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

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

сообщения электронной почты SMTP, SOAP-сообщения Веб-сервисов, DCOM для удаленных

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

специальные протоколы связи на базе TCP/IP. Если бизнес-слой и слой доступа к данным

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

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

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

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

на основе сообщений. Это обеспечивает более естественную организацию

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

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

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

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

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

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

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

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

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

данных.

 Для защиты каналов связи используйте IPSec и SSL; конфиденциальные данные

защищайте с помощью шифрования. Также применяйте цифровые подписи для

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

 Если приложение должно потреблять или отправлять большие наборы или объемы

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

производительность и сеть. Выбирайте более эффективные протоколы связи, такие как

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

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

и SOAP, либо специальные бинарные форматы, если от приложения не требуется

поддерживать открытые стандарты связи.

Более подробно взаимодействие клиентов и слоев приложения рассматривается в главе 18,

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

Композиция

Реализация интерфейса с использованием шаблона проектирования Composition

(Композиция), когда UI состоит из отдельных модулей или форм, загружаемых динамически

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

приложения, особенно если оно предоставляет сложный UI, как это обычно бывает во многих

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

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

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

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

задержки при запуске. Также продумайте поддержку персонализации интерфейса и

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

соответственно собственным требованиям. При проектировании стратегии композиции

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

 На основании функциональных спецификаций и требований определите необходимые

типы компонентов интерфейса. Это могут быть компоненты Windows Forms, WPF-

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

модули.

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

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

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

модульных атомарных составных частей поможет шаблон Composite View. Или в

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

такую как Composite Client Application Guidance группы patterns & practices, или

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

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

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

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

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

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

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

несвязанное взаимодействие посредством шаблонов Publish/Subscribe или Command.

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

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

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

формы, используемой в составном интерфейсе.

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

компонентов интерфейса.

Управление конфигурацией

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

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

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

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

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

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

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

и другие данные UI локального профиля пользователя. При проектировании стратегии

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

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

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

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

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

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

динамического обновления конфигурации.

 Выбирайте локальное или централизованное хранение данных. Управляемые

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

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

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

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

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

 Определите конфиденциальные конфигурационные данные и реализуйте подходящий

механизм их защиты при передаче по сети, локальном хранении и даже при хранении

в памяти.

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

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

локальные настройки.

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

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

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

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

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

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

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

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

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

реализован механизм трансляции, обеспечивающий их преобразование. Но нельзя забывать,

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

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

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

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

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

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

защиты от возникающих в результате этого ошибок.

 Если клиент предполагает потреблять большие объемы данных, разделение данных на

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

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

несогласованность локальных копий и исходных данных. Для этого могут

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

 В сценариях без постоянного подключения отслеживайте подключение и реализуйте

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

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

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

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

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

оптимистичной или пессимистичной блокировки.

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

рассматривается в разделе «Вопросы обработки данных» далее в этой главе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

пользователя. Однако такие ошибки, как неоднократная неудачная попытка

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

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

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

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

 Выработайте общую стратегию обработки исключений. Она может включать такие

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

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

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

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

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

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

группой patterns & practices Enterprise Library.

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

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

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

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

и предоставлять отчет о состоянии приложения администраторам.

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

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

аудита конфиденциальных данных. В случае необходимости шифруйте данные и

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

каналам.

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

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

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

бизнес-логикой.

Более подробно обработка исключений рассматривается в главе 17, «Сквозная

функциональность».

Удобство и простота обслуживания

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

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

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

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

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

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

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

исправление и управление версиями. При проектировании стратегии обслуживания

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

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

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

чтобы гарантировать непротиворечивость и совместимость версий всех используемых

им компонентов.

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

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

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

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

инструментами, такими как Microsoft System Center.

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

компоненты. Это позволит заменять отдельные компоненты в зависимости от

требований, сценариев времени выполнения и требований или предпочтений

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

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

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

 Реализуйте для приложения соответствующее протоколирование и аудит. Эти данных

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

решении проблем, возникающих во время выполнения.

Более подробно вопросы удобства и простоты обслуживания обсуждаются в главе 16,

«Показатели качества».

Слой представления

Слой представления – это часть приложения, которую видит пользователь и с которой он

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

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

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

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

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

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

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

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

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

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

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

Separated Presentation. Это упростит обновление частей приложения, позволит

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

улучшит тестируемость.

 Реализуйте гибкие и легко обновляемые стратегии и механизмы управления и

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

как Command, Publish/Subscribe и Observer, для отделения команд и навигации от

компонентов, это позволит улучшить тестируемость.

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

данных в виде таблиц или множества строк. Это сократит объем необходимого кода и

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

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

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

обновления данных.

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

отображении содержимого документов или HTML в других элементах UI. Обеспечьте

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

которое может находиться в документах.

 Обеспечьте интернационализацию UI с последующей локализацией для всех

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

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

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

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

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

Вопросы проектирования слоя представления подробно рассматриваются в главе 6,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 При наличии больших объемов данных состояния храните их локально на диске. Если

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

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

или файл на жестком диске.

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

защиты через использование шифрования и/или цифровых подписей.