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

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

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

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

Используйте набор протоколов Internet Protocol Security (IPSec)1 для защиты данных, передаваемых между физическими уровнями.

Используйте шифрование по протоколу Secure Sockets Layer (SSL)2 для защиты вызовов удаленных Веб-сервисов компонентами бизнес-слоя.

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

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

1.Создайте дизайн бизнес-слоя в первом приближении. Определите, кто будет использовать бизнес-слой: слой представления, слой сервисов или другие приложения. Это определит тактику методов доступа к бизнес-слою. Далее определите требования безопасности для бизнес-слоя, требования и стратегию валидации. Руководствуйтесь рекомендациями раздела «Специальные вопросы проектирования» данной главы, это поможет учесть все факторы при создании дизайна в первом приближении.

2.Спроектируйте компоненты бизнес-слоя. При проектировании и реализации приложения могут использоваться несколько типов компонентов бизнес-слоя. Примерами таких компонентов являются компоненты бизнес-процесса, служебные компоненты и вспомогательные компоненты. К факторам, влияющим на выбор структуры компонентов бизнес-слоя, относятся разные аспекты дизайна приложения, требования к транзакциям и правила обработки. Более подробно эти вопросы рассматриваются в главе 12, «Проектирование компонентов бизнес-слоя».

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

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

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

сущности должны обеспечивать проверку данных, размещаемых в сущности. Кроме того, бизнес-сущности обеспечивают свойства и операции для доступа и инициализации данных сущности. Более подробно эти вопросы рассматриваются в главе 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/enus/library/cc304800.aspx.

Более подробно шаблоны Data-Driven Workflow, Human Workflow, Sequential Workflow и StateDriven Workflow рассматриваются в статье «Windows Workflow Foundation Overview» (Обзор

Windows Workflow Foundation) по адресу http://msdn.microsoft.com/enus/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.nlogproject.org/introduction.html.

8

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

Обзор

В данной главе приводятся основные рекомендации по проектированию слоя доступа к данным приложения. Из нее вы узнаете, какое место слой доступа к данным занимает в типовой архитектуре многослойного приложения, какие компоненты обычно включает и с какими основными проблемами придется столкнуться при проектировании слоя доступа к данным. Здесь вы найдете советы по проектированию, рекомендуемые этапы проектирования, соответствующие шаблоны проектирования и технологии. На рис. 1 показано место слоя доступа к данным в общей архитектуре приложения.

Рис. 9

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

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

Компоненты доступа к данным. Эти компоненты абстрагируют логику, необходимую для доступа к базовым хранилищам данных. Они обеспечивают централизацию общей функциональности доступа к данным, что способствует упрощению настройки и обслуживания приложения. Некоторые инфраструктуры доступа к данным могут требовать, чтобы общая логика доступа к данным была определена и реализована в отдельных вспомогательных или служебных компонентах доступа к данным, пригодных для повторного использования. Другие инфраструктуры доступа к данным, включая многие инфраструктуры объектнореляционного сопоставления (Object/Relational Mapping, O/RM), реализуют такие компоненты автоматически, сокращая объем кода доступа к данным, который должен написать разработчик.

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