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

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

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

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

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

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

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

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

Авторизация

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

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

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

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

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

 Защитите ресурсы, применяя авторизацию на основании удостоверений, учетных

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

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

разрешений.

 Применяйте авторизацию на основании ролей для бизнес-решений, авторизацию

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

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

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

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

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

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

больших ресурсов, чем вызов напрямую.

 Не смешивайте код авторизации и код обработки бизнес-задач в одном

компоненте.

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

чтобы инфраструктура авторизации не создавала существенные издержки

производительности.

Кэширование

Проектирование соответствующей стратегии кэширования для бизнес-слоя важно с точки

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

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

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

решение о том, когда и как будут загружаться кэшированные данные. Чтобы обеспечить

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

процесса пакетной передачи. При проектировании стратегии кэширования руководствуйтесь

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

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

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

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

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

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

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

 Рассмотрите возможность кэширования данных в бизнес-слое в готовом к

использованию виде.

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

обеспечьте механизм защиты таких данных в кэше.

 Рассмотрите, как развертывание Веб-фермы повлияет на дизайн механизмов

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

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

поддерживать синхронизацию кэшированных данных.

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

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

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

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

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

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

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

 Избегайте циклических зависимостей. Бизнес-слой должен знать только о слое,

расположенном под ним (слое доступа к данным), и ничего не знать о слое над ним

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

слою напрямую).

 Реализуйте слабо связанный интерфейс через абстракцию. Этого можно достичь за

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

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

абстракций, а не от других компонентов (принцип инверсии зависимостей). Этапы

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

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

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

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

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

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

компонента. Всегда избегайте смешения логики доступа к данным с бизнес-логикой

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

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

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

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

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

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

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

противном случае, оно будет уязвимым для атак Отказа в обслуживании (Denial of Service, DoS)

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

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

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

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

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

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

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

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

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

приложения.

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

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

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

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

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

анализа основных причин ошибок и сбоев.

 Убедитесь, что перехватываете исключения, которые не будут перехвачены где-

либо в другом месте (например, глобальном обработчике ошибок), и очищайте

ресурсы и состояние после возникновения исключения.

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

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

исключениях и при этом не разглашать конфиденциальных данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

бизнес-слоя. Для реализации функциональности обработки исключений и

протоколирования используйте библиотеку Enterprise Library от patterns & practices

или решения сторонних производителей, такие как Сервисы протоколирования

Apache (Apache Logging Services) «log4Net» или сервис «NLog» Ярослава Ковальского

(Jarosław Kowalski).

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

системы и бизнес-процесса.

 Не храните конфиденциальные бизнес-данные в файлах журнала.

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

функциональность бизнес-слоя.

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

функциям бизнес-слоя.

Валидация

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

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

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

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

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

угрозам безопасности, как межсайтовые атаки внедрением сценариев (cross-site scripting, XSS),

атаки типа внедрение SQL-кода, переполнение буфера и другие типы атак посредством

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

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

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

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

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

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

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

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

 Ограничивайте, отклоняйте и очищайте пользовательский ввод. Иначе говоря,

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

Проводите проверку длины, диапазона, формата и типа вводимых данных.

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

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

производительности и безопасности в среде производственной эксплуатации. При

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

 Если не предъявляются особые требования по размещению бизнес-слоя на

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

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

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

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

производительности приложения используйте протокол TCP.

 Используйте набор протоколов Internet Protocol Security (IPSec)

для защиты

данных, передаваемых между физическими уровнями.

 Используйте шифрование по протоколу Secure Sockets Layer (SSL)

для защиты

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

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

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

основных составляющих этого слоя: компонентов бизнес-слоя, бизнес-сущностей и

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

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

бизнес-слоя:

1. Создайте дизайн бизнес-слоя в первом приближении. Определите, кто будет

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

приложения. Это определит тактику методов доступа к бизнес-слою. Далее

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

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

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

дизайна в первом приближении.

2. Спроектируйте компоненты бизнес-слоя. При проектировании и реализации

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

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

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

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

приложения, требования к транзакциям и правила обработки. Более подробно эти

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

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

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

Безопасные Интернет-протоколы (прим. переводчика).

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

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

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

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

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

4. Спроектируйте компоненты рабочего процесса. Существует масса сценариев, в

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

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

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

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

рабочего процесса. Более подробно эти вопросы рассматриваются в главе 14,

«Проектирование компонентов рабочего процесса».

Проектированию и использованию компонентов в приложениях посвящена глава 10,

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

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

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

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

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

Категория

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

Компоненты бизнес-слоя

Application Façade (Фасад приложения). Централизует и агрегирует

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

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

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

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

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

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

Бизнес-сущности

Domain Model (Модель предметной области). Набор бизнес-

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

между ними.

Entity Translator (Транслятор сущностей). Объект, преобразующий

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

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

Table Module (Модуль таблицы). Единый компонент, реализующий

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

данных.

Рабочие процессы

Data-Driven Workflow (Управляемый данными рабочий процесс).

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

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

процессе или системе.

Human Workflow (Рабочий процесс, управляемый оператором).

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

Sequential Workflow (Последовательный рабочий процесс).

Рабочий процесс, включающий задачи, выполняющиеся в

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

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

State-Driven Workflow (Управляемый состоянием рабочий

процесс). Рабочий процесс, включающий задачи, последовательность

выполнения которых определяется состоянием системы.

Более подробно шаблон Façade рассматривается в главе 4, «Структурные шаблоны», книги

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

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

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

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

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

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

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

Более подробно шаблон Entity Translator рассматривается в статье «Useful Patterns for Services»

(Полезные шаблоны для сервисов) по адресу http://msdn.microsoft.com/en-

us/library/cc304800.aspx.

Более подробно шаблоны Data-Driven Workflow, Human Workflow, Sequential Workflow и State-

Driven Workflow рассматриваются в статье «Windows Workflow Foundation Overview» (Обзор

Windows Workflow Foundation) по адресу http://msdn.microsoft.com/en-

us/library/ms734631.aspx и «Workflow Patterns» (Шаблоны рабочего процесса) по адресу

http://www.workflowpatterns.com/.

Предложения группы patterns & practices

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

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

 «Enterprise Library» по адресу http://msdn.microsoft.com/en-us/library/cc467894.aspx.

 «Unity» (механизм внедрения зависимостей) по адресу

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

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

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

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

Более подробно интеграция бизнес-слоев рассматривается в статье «Integration Patterns»

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

Сведения о сервисах протоколирования Apache (Apache Logging Services) «log4Net» можно

найти по адресу http://logging.apache.org/log4net/index.html.

Сведения о сервисе «NLog» Ярослава Ковальского можно найти по адресу http://www.nlog-

project.org/introduction.html.

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

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

к данным

Обзор

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

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

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

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

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

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

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

Рис. 9

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

Слой доступа к данным может включать следующие компоненты:

 Компоненты доступа к данным. Эти компоненты абстрагируют логику,

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

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

упрощению настройки и обслуживания приложения. Некоторые инфраструктуры

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

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

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

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

реляционного сопоставления (Object/Relational Mapping, O/RM), реализуют такие

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

должен написать разработчик.

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

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

управления семантикой взаимодействия с этим конкретным сервисом. Агенты

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

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

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

автономном режиме и базовое преобразование между форматом данных,

предоставляемых сервисом, и форматом, поддерживаемым вашим приложением.

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

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

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

компонентов слоя доступа к данным».

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

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

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

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

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

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

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

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

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

перечислением преимуществ и соображений относительно применения в том или

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

«Матрица технологий доступа к данным».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

объекты предметной области, типизированные наборы данных (Typed DataSet) и

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

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

приложения.

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

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

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

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

используются шаблоны Domain Model или Table Module либо механизмы Объектно-

реляционного сопоставления (Object/Relational Mapping, O/RM), однако, бизнес-