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

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

Предложения группы patterns & practices, Smart Client Software Factory и Composite Client

Application Guidance, более подробно рассматриваются в разделе «Предложения patterns &

practices» далее в этой главе.

Аспекты производительности

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

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

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

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

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

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

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

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

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

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

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

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

задержки или обрывов связи.

 Реализуйте кэширование данных, которые будут выводиться на экран

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

данные, отображаемые в биржевых сводках.

 Как правило, избегайте сохранения данных сеанса или кэширования данных

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

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

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

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

данных в Веб-фермах или фермах серверов приложений при хранении или

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

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

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

данных, и задавайте размер страницы, соответствующий отображаемому объему

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

случае крайней необходимости.

 Пользуйтесь ViewState в ASP.NET аккуратно, поскольку это приводит к увеличению

объема данных, участвующего в каждом обращении к серверу, и может негативно

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

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

сохранения сеансов.

Этапы проектирования слоя представления

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

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

необходимые аспекты.

1. Выберите тип клиента. Выберите тип клиента, удовлетворяющий требованиям и

соответствующий ограничениям инфраструктуры и развертывания организации.

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

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

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

можно найти в главе 20, «Выбор типа приложения».

2. Выберите технологию для реализации слоя представления. Определитесь в общих

чертах с функциональностью UI и слоя представления и выберите технологию UI,

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

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

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

типа приложения, приведены в приложении В, «Матрица технологий слоя

представления».

3. Спроектируйте пользовательский интерфейс. Определитесь с тем, должен ли UI

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

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

шаблонов раздельного представления, таких как Presentation Model, MVC и MVP.

Следуйте рекомендациям, приведенным в разделах Композиция, Навигация,

Взаимодействие с пользователем и Пользовательский интерфейс данной главы

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

Доступные типы компонентов рассматриваются в главе 11, «Проектирование

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

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

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

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

исключений. Реализация соответствующих стратегий проверки, обработки

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

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

5. Выберите стратегию реализации бизнес-логики. Вынесите бизнес-логику, чтобы

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

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

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

общие принципы выбора:

◦ Валидация в UI. В простых приложениях, где бизнес-логика используется

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

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

включать в компоненты UI нельзя.

◦ Компоненты обработки бизнес-задач. Для более сложных приложений,

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

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

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

компонентами UI.

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

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

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

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

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

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

◦ Управление бизнес-правилами. В приложениях, которые должны

поддерживать сложную проверку, координирование процессов и логику

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

бизнес-правилами, такой как Microsoft BizTalk® Server.

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

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

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

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

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

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

используйте следующие техники:

◦ Прямые вызовы методов. Если слой, с которым происходит

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

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

◦ Веб-сервисы. Используйте интерфейс Веб-сервиса, если хотите разделить

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

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

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

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

рамках внутренней сети, используйте WCF-службу, работающую по

протоколу TCP. Если бизнес-логика или логика доступа к данным будет

использоваться слоем представления через Интернет, используйте WCF-

службу, работающую по протоколу HTTP. Если в бизнес-логике или логике

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

асинхронную связь с помощью WCF и очереди сообщений.

Более подробно реализация соответствующих стратегий связи рассматривается в главе 18,

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

Шаблоны проектирования

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

представлены в следующей таблице. Рассмотрите возможности применения этих шаблонов

при принятии проектных решений для каждой из категорий.

Категория

Шаблоны

Кэширование

Cache Dependency (Кэш с зависимостью). Использует внешние данные

для определения состояния данных, хранящихся в кэше.

Page Cache (Кэш страниц). Улучшает время ответа динамических Веб-

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

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

воссоздания.

Композиция и компоновка

Composite View (Составное представление). Сочетает отдельные

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

Шаблон Presentation Model (Model-View-ViewModel). Разновидность

шаблона Model-View-Controller (MVC), приспособленная для

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

представления (View) занимаются, главным образом, дизайнеры, а не

обычные разработчики.

Template View (Представление по шаблону). Реализует представление

общего шаблона и создает представления на базе этого шаблонного

представления.

Transform View (Представление с преобразованием). Преобразует

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

отображения в UI.

Two-Step View (Двухэтапное представление). Преобразует модель

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

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

добавляя необходимое форматирование.

Управление

исключениями

Exception Shielding (Экранирование исключений). При возникновении

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

внутренней реализации.

Навигация

Application Controller (Контроллер приложений). Единое место

обработки навигации между окнами.

Front Controller (Контроллер запросов). Шаблон только для Веб,

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

через один объект-обработчик, который можно изменять во время

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

Page Controller (Контроллер страниц). Принимает ввод из запроса и

обрабатывает его для конкретной страницы или действия Веб-сайта.

Command (Команда). Инкапсулирует обработку запроса в отдельный

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

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

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

Asynchronous Callback (Асинхронный обратный вызов). Выполняет

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

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

завершении выполнения задачи.

Chain of Responsibility (Цепочка обязанностей). Предоставляя

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

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

Более подробно шаблон Page Cache рассматривается в статье «Enterprise Solution Patterns Using

Microsoft .NET» (Шаблоны корпоративных решений для Microsoft .NET) по адресу

http://msdn.microsoft.com/en-us/library/ms998469.aspx.

Более подробно шаблоны Application Controller, Front Controller, Page Controller, Template View,

Transform View и Two-Step View рассматриваются в книге Мартина Фаулера «Архитектура

корпоративных приложений». Addison-Wesley, 2002. Или по адресу

http://martinfowler.com/eaaCatalog.

Более подробно шаблоны Composite View и Presentation Model рассматриваются в статье

«Patterns in the Composite Application Library» (Шаблоны в библиотеке составного приложения)

по адресу http://msdn.microsoft.com/en-us/library/dd458924.aspx.

Более подробно шаблон Chain of Responsibility рассматривается в статье «Patterns in Practice»

(Шаблоны на практике) по адресу http://msdn.microsoft.com/en-us/magazine/cc546578.aspx.

Шаблону Command посвящена глава 5, «Поведенческие шаблоны», в книге Эрика Гамма,

Ричарда Хелма, Ральфа Джонсона и Джона Влиссидеса «Приемы объектно-

ориентированного проектирования. Паттерны проектирования». Питер, 2007.

Более подробно шаблон Asynchronous Callback рассматривается в статье «Creating a Simplified

Asynchronous Call Pattern for Windows Forms Applications» (Создание упрощенного шаблона

асинхронных вызовов для приложений Windows Forms) по адресу

http://msdn.microsoft.com/en-us/library/ms996483.aspx.

Более подробно шаблоны Exception Shielding и Entity Translator рассматриваются в статье

«Useful Patterns for Services» (Полезные шаблоны для сервисов) по адресу

http://msdn.microsoft.com/en-us/library/cc304800.aspx.

Предложения patterns & practices

Узнать о дополнительных предложениях группы Microsoft patterns & practices можно из

следующих источников:

 «Composite Client Application Guidance» по адресу http://msdn.microsoft.com/en-

us/library/cc707819.aspx.

 «Smart Client Software Factory» по адресу http://msdn.microsoft.com/en-

us/library/aa480482.aspx.

 «Web Client Software Factory» по адресу http://msdn.microsoft.com/en-

us/library/bb264518.aspx.

Дополнительные источники

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

http://www.microsoft.com/architectureguide.

 «Choosing the Right Presentation Layer Architecture» (Как правильно выбрать

архитектуру слоя представления) по адресу http://msdn.microsoft.com/en-

us/library/aa480039.aspx.

 Распределенная система кэширования объектов в памяти «memcached» по адресу

http://www.danga.com/memcached/.

 «Microsoft Inductive User Interface Guidelines» (Руководство по Microsoft Inductive

User Interface) по адресу http://msdn.microsoft.com/en-us/library/ms997506.aspx.

 «Microsoft Project Code Named ‘Velocity’» (Проект Microsoft под кодовым названием

‘Velocity’) по адресу http://msdn.microsoft.com/en-us/data/cc655792.aspx.

 «User Interface Text Guidelines» (Руководство по проектированию текстовой части

пользовательского интерфейса) по адресу http://msdn.microsoft.com/en-

us/library/bb158574.aspx.

 «Design and Implementation Guidelines for Web Clients» (Руководство по

проектированию и реализации Веб-клиентов) по адресу

http://msdn.microsoft.com/en-us/library/ms978631.aspx.

 «Web Presentation Patterns» (Шаблоны представления в Веб) по адресу

http://msdn.microsoft.com/en-us/library/ms998516.aspx.

Рекомендации по

проектированию бизнес-слоя

Обзор

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

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

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

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

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

соответствующие шаблоны проектирования и технологии. На рис. 1 показано место бизнес-

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

Рис. 8

Бизнес-слой в типовом приложении и компоненты, которые он может включать

Бизнес-слой обычно включает следующие компоненты:

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

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

бизнес-операций в одну, что упрощает использование бизнес-логики. Это

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

необходимости знать детали компонентов бизнес-слоя и отношения между ними.

 Компоненты бизнес-логики. Бизнес-логика, как и любая логика приложения,

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

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

непротиворечивости и действительности данных. Чтобы создать наилучшие условия

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

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

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

категории:

◦ Компоненты бизнес-процесса. После того, как компоненты UI получили

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

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

процесса. Большинство бизнес-процессов включают множество этапов,

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

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

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

долгосрочные многоэтапные бизнес-процессы и могут быть реализованы с

помощью инструментов управления бизнес-процессами. Они работают с

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

операции с компонентами рабочего процесса. Более подробно компоненты

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

рабочего процесса».

◦ Компоненты бизнес-сущностей. Бизнес-сущности, или более общее название –

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

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

(Customers) или заказы (Orders). Они хранят значения данных и предоставляют

их через свойства; содержат бизнес-данные приложения и управляют ими; и

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

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

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

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

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

главе 13, «Проектирование бизнес-сущностей».

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

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

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

компонентов бизнес-слоя».

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

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

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

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

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

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

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

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

 Убедитесь в необходимости отдельного бизнес-слоя. По возможности всегда

создавайте отдельный бизнес-слой, это способствует повышению удобства

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

небольшим числом или вообще без бизнес-правил (кроме валидации данных).

 Определитесь с ответственностями и потребителями бизнес-слоя. Это поможет

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

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

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

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

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

 Не смешивайте в бизнес-слое компоненты разных типов. Используйте бизнес-слой

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

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

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

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

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

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

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

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

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

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

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

Объекты переноса данных (Data Transfer Objects, DTO).

 Избегайте тесного связывания между слоями. При создании интерфейса бизнес-

слоя применяйте принципы абстракции для максимального ослабления

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

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

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

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

подробно эти вопросы рассматриваются в главе 5, «Рекомендации по

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

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

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

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

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

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

 Аутентификация

 Авторизация

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

 Связывание и связность

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

 Протоколирование, аудит и инструментирование

 Валидация

Аутентификация

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

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

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

перехватом сеансов и других типов атак. При проектировании стратегии аутентификации

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

 Избегайте аутентификации в бизнес-слое, если она будет использоваться только

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

пределах границы доверия. Передавайте удостоверение вызывающего в бизнес-

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

основании ID исходной вызывающей стороны.

 Если предполагается разделять бизнес-слой между многими приложениями,

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

применения механизма единой регистрации. Избегайте создания собственных

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

механизмами платформы.

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

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

управления доступом (access control list, ACL) исходного вызывающего, рассмотрите

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

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

на основании разрешений ACL исходного вызывающего, рассмотрите возможность

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

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

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

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