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

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

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

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

выполнять доступ к удаленным данным или функциональности.

 Насыщенные Интернет-приложения. Приложения этого типа могут поддерживать

множество платформ и браузеров. Насыщенные Интернет-приложения выполняются

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

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

 Сервисные приложения. Сервисы предоставляют бизнес-функциональность для

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

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

соответствующих XML-схемам и передаваемых по транспортным каналам. Целью

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

клиентом и сервером.

 Веб-приложения. Приложения этого типа, как правило, поддерживают сценарии с

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

разнообразнейших операционных системах и на разных платформах.

Существует множество других более специализированных типов приложений. Как правило,

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

данном списке.

Типы приложений

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

приложений.

Тип приложения

Преимущества

Недостатки

Мобильные приложения

Поддержка портативных

устройств.

Доступность и простота

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

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

Поддержка сценариев без

подключения и сценариев без

постоянного подключения.

Ограниченные возможности

ввода и навигации.

Ограниченная область

отображения экрана.

Насыщенные клиентские

приложения

Возможность использования

ресурсов клиента.

Лучшее время отклика,

насыщенная функциональность

UI и улучшенное взаимодействие

с пользователем.

Очень динамичное

взаимодействие с коротким

временем отклика.

Поддержка сценариев без

подключения и сценариев без

Сложность развертывания; при

этом широкий выбор вариантов

установки, таких как ClickOnce,

Windows Installer и XCOPY.

Сложности обеспечения

совместимости версий.

Зависимость от платформы.

постоянного подключения.

Насыщенные Интернет-

приложения (RIA)

Такие же насыщенные

возможности пользовательского

интерфейса, как и для

насыщенных клиентов.

Поддержка насыщенных и

потоковых мультимедиа и

графики.

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

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

(насыщенными) такими же, как и

для Веб-клиентов.

Простота обновления и смены

версий.

Поддержка различных платформ

и браузеров.

Больший объем памяти,

занимаемый на клиенте, по

сравнению с Веб-приложением.

Ограниченное использование

ресурсов клиента по сравнению с

насыщенным клиентским

приложением.

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

на клиенте подходящей среды

выполнения.

Сервисные приложения

Слабо связанное

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

и сервером.

Могут использоваться

различными и

невзаимосвязанными

приложениями.

Поддержка для обеспечения

возможности взаимодействия.

Отсутствие поддержки UI.

Зависимость от возможности

сетевого подключения.

Веб-приложения

Широко доступный и основанный

на стандартах UI,

поддерживаемый на многих

платформах.

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

внесения изменений.

Необходимость устойчивого

сетевого подключения.

Сложно обеспечить насыщенный

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

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

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

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

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

 Мобильное приложение

 Насыщенное клиентское приложение

 Насыщенное Интернет-приложение

 Сервис

 Веб-приложение

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

 Глава 26 «Проектирование размещаемых сервисов и сервисов в облаке»

 Глава 27 «Проектирование офисных бизнес-приложений»

 Глава 28 «Проектирование LOB-приложений SharePoint»

Мобильное приложение

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

включающее слой пользовательского интерфейса (представления), бизнес-слой и слой доступа

к данным (рис. 1).

Рис. 26

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

Мобильное приложение может быть тонким Веб-клиентом или насыщенным клиентом. Если

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

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

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

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

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

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

сервисы типа S+S (ПО + сервисы) и Веб-сервисы. Часто мобильному клиентскому приложению

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

сервисам через специальную серверную инфраструктуру.

Используйте мобильные приложения, если:

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

 Приложение поддерживает простой UI, подходящий для использования на

небольшом экране.

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

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

клиентское приложение.

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

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

мобильное Веб-приложение.

Проектированию мобильных приложений посвящена глава 24, «Проектирование мобильных

приложений»

Насыщенное клиентское приложение

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

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

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

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

клиентское приложение структурировано как многослойное приложение, включающее слой

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

Рис. 27

Типовая структура насыщенного клиентского приложения

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

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

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

сервисы типа S+S и Веб-сервисы.

Используйте насыщенные клиентские приложения, если:

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

подключения.

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

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

время отклика.

 UI приложения должен обеспечивать насыщенную функциональность и

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

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

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

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

насыщенных клиентских приложений».

Насыщенное Интернет-приложение

Насыщенное Интернет-приложение (RIA) выполняется в браузере в изолированной

программной среде. К преимуществам RIA, по сравнению с традиционными Веб-

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

время отклика приложения и эффективность работы с сетью. Как правило, RIA структурировано

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

(представления), бизнес-слой и слой доступа к данным (рис. 3).

Рис. 28

Типовая структура насыщенного Интернет-приложения

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

размещаемой среды выполнения (такой как среда выполнения XAML или Silverlight).

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

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

выполнения.

Используйте насыщенные Интернет-приложения, если:

 Приложение должно поддерживать насыщенные мультимедиа и обеспечивать

представление, насыщенное графическими элементами.

 Приложение должно обеспечивать более насыщенный, интерактивный

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

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

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

 Требуется обеспечить простую модель развертывания в Веб.

Проектированию насыщенных Интернет-приложений посвящена глава 23, «Проектирование

насыщенных Интернет-приложений».

Сервис

В контексте данного руководства сервис – это открытый интерфейс, обеспечивающий доступ к

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

вызывающей стороне, которая потребляет этот сервис. Как правило, сервисное приложение,

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

включающее слой сервисов, бизнес-слой и слой доступа к данным (рис. 4).

Рис. 29

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

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

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

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

сервисы ориентируются на обмен сообщениями. Это означает, что интерфейсы описываются

WSDL-документом, и операции вызываются с помощью построенных на XML-схемах

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

взаимодействия через описание сообщения/интерфейса сервисы поддерживают гетерогенную

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

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

Используйте сервисные приложения, если:

 Приложение будет предоставлять функциональность, не требующую UI.

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

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

приложениями.

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

приложениями через Интернет, интранет или на локальном компьютере.

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

сервисных приложений».

Веб-приложение

Ядро Веб-приложения – его логика на стороне сервера. Эта логика может состоять из

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

включающая слой представления, бизнес-слой и слой доступа к данным (рис. 5).

Рис. 30

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

Как правило, Веб-приложение осуществляет доступ к хранилищу данных на удаленном

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

приложениями, включая размещаемые сервисы типа ПО + сервисы и Веб-сервисы.

Используйте Веб-приложения, если:

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

предлагает насыщенное Интернет-приложение.

 Требуется обеспечить простую модель развертывания в Веб.

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

 Приложение должно быть доступным через Интернет.

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

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

процессора.

Проектированию Веб-приложений посвящена глава 21, «Проектирование Веб-приложений».

Проектирование Веб-

приложений

Обзор

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

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

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

рекомендации по выбору шаблонов и технологий.

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

браузер или специализированный агент пользователя. Браузер создает HTTP-запросы к

определенным URL, которые сопоставляются с ресурсами на Веб-сервере. Сервер формирует

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

возвращает их клиенту. Ядро Веб-приложения – это его логика на стороне сервера. Такое

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

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

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

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