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