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

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

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

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

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

и тому же серверу.

 Используйте в Веб-ферме управление сеансами в процессе, только если реализуете

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

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

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

сервер базы данных.

Более подробно шаблоны и сценарии развертывания рассматриваются в главе 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/en-

us/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/.

Проектирование мобильных

приложений

Обзор

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

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

компоненты мобильного приложения; специальные аспекты мобильных приложений, такие

как развертывание, энергопотребление и синхронизация; а также ключевые шаблоны и

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

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

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

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

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

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

сервере. Рис. 1 иллюстрирует типовую архитектуру насыщенного клиентского мобильного

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

Рис. 41

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

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

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

Бизнес-слой, если таковой имеется, обычно включает компоненты бизнес-логики, все

компоненты бизнес-процесса и бизнес-сущностей, необходимые приложению, и фасад, если

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

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

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

число компонентов. Более подробно многослойный дизайн рассматривается в главе 5,

«Рекомендации по проектированию многослойных приложений». Больше сведений о

компонентах каждого слоя можно найти в главе 10, «Рекомендации по проектированию

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

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

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

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

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

соответствие всем выдвигаемым требованиям:

 Определитесь, создается ли насыщенный клиент, тонкий Веб-клиент или

насыщенное Интернет-приложение (RIA). Если создаваемое приложение требует

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

проектируйте насыщенный клиент. Насыщенное клиентское приложение будет

сложнее устанавливать и обслуживать. Если приложение может зависеть от обработки

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

клиент. Если приложению необходим насыщенный UI, оно имеет только

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

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

 Определите, какие типы устройств будут поддерживаться. При выборе

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

характеристики производительности ЦП, объем памяти и хранилища, а также

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

ограничения организации. Может потребоваться специальное оборудование, такое

как глобальная система определения местоположения (global positioning system, GPS)

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

выбор устройства.

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

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

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

. Если мобильному приложению

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

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

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

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

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

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

исходя из простоты разработки.

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

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

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

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

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

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

Основными ограничениями являются память, время работы батареи, способность

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

пропускная способность сети.

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

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

Так как его просто нет (прим. научного редактора).

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

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

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

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

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

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

 Учитывайте ограничения, налагаемые ресурсами устройства, такие как время

работы батареи, объем памяти и частота процессора. Каждое проектное решение

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

батареи мобильного устройства. Как правило, первостепенным ограничивающим

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

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

процессора – все эти аспекты оказывают влияние на общее энергопотребление. При

недостаточном объеме доступной памяти операционная система Windows Mobile

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

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

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

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

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

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

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

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

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

 Аутентификация и авторизация

 Кэширование

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

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

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

 Особенности устройств

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

 Протоколирование

 Портирование приложений

 Управление энергопотреблением

 Синхронизация

 Тестирование

 Пользовательский интерфейс

 Валидация

Аутентификация и авторизация

Проектирование эффективной стратегии аутентификации и авторизации имеет большое

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

компьютеру, обнаружение по Bluetooth, синхронизацию по Виртуальной частной сети

(Virtual Private Network, VPN) и локальную синхронизацию карты памяти SD.

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

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

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

настольных платформах, будут доступны и на мобильной платформе, даже если

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

управления доступом (ACL) и, следовательно, нет безопасности файлов на уровне

операционной системы.

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

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

где и как проводить аутентификацию.

Кэширование

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

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

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

обращений к сети и предотвратить ненужную повторную обработку. Принимая решение о том,

какие данные кэшировать, учитывайте ограниченность ресурсов устройства; доступный объем

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

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

 Обозначьте требования по производительности. Например, определите минимальное

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

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

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

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

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

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

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

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

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

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

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

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

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

 Правильно выберите месторасположение кэша. Он может располагаться в устройстве,

в мобильном шлюзе или на сервере базы данных. Применяйте для кэширования не

память устройства, а SQL Server Compact Edition, поскольку используемая

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

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

кэшировании данных на съемных носителях.

Более подробно проектирование стратегии кэширования рассматривается в главе 17,

«Сквозная функциональность».

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

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

беспроводной («по воздуху») и проводной связи, и также более специализированных видов

связи, таких как Bluetooth или Infrared Data Association (IrDA). При беспроводном

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

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

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

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

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

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

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

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

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

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

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

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

блокировку пользовательского интерфейса. Используйте соответствующие протоколы

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

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

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

сохранения заряда батареи.

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

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

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

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

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

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

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

обеспечьте защиту данных, передаваемых по VPN. При этом не забывайте о влиянии

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

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

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

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

ограниченной полосы пропускания.

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

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

хранением.

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

обмен сообщениями».

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

При проектировании управления конфигурацией устройства проработайте вопросы

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

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

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

 Правильно выберите формат конфигурационных данных. Отдавайте предпочтение

бинарным форматам, а не XML, чтобы сократить объем занимаемой памяти. Снизить

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

хранения данных конфигурации и состояния. Шифруйте конфиденциальные данные,

хранящиеся в конфигурационных файлах.

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

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

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

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

конфигурации.

 Если для хранения данных предприятия используется Microsoft SQL Server 2005 или

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

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

производителя

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

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

 Для инфраструктуры Active Directory используйте интерфейс System Center Mobile

Device Manager (Диспетчер мобильных устройств), он обеспечит управление групповой

конфигурацией, аутентификацией и авторизацией устройств. Требования Mobile Device

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

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

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

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

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

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

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

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

синхронизации, такую как SQL Server Compact Edition. Создавайте собственный

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

не отвечают поставленным требованиям.

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

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

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

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

подключения, используйте транзакции в SQL Server Mobile.

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

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

наличие съемного хранилища перед записью в него или использованием

FlushFileBuffers (Очистка буферов файлов).

 При использовании XML для хранения или передачи данных принимайте во внимание

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

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

алгоритмы сжатия или не-XML методы передачи.

 Проектируйте эффективные методы доступа к базе данных и обработки данных,

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

Использование типизированных объектов вместо DataSet позволит сократить

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

только чтение данных, используйте объекты DataReader. Избегайте операций,

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

Если в качестве хранилища на мобильном устройстве используется SQL Server Compact

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

редактора).