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

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

Шаг 4 – Выработка стратегии обработки бизнес-правил

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

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

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

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

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

Шаг 5 – Выбор шаблонов, соответствующих требованиям

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

	Шаблон			Рекомендации
Adapter (Адаптер)				Обеспечивает возможность совместной работы классов с несовместимыми
				интерфейсами, позволяя разработчикам реализовывать наборы полиморфных
				классов, обеспечивающих альтернативные реализации существующего класса.
Command (Команда)				Рекомендуется для насыщенных клиентских приложений с меню, панелями
				инструментов и реализациями клавишных комбинаций быстрого вызова,
				которые используются для выполнения одних и тех же команд из разных
				компонентов. Также может использоваться для реализации команд с шаблоном
				Supervising Presenter.
Chain of Responsibility				Объединяет обработчики запросов так, что каждый обработчик проверяет
(Цепочка				запрос и либо обрабатывает его, либо передает следующему обработчику.
обязанностей)				Альтернативой этому шаблону являются выражения «if, then, else» с
				возможностью обработки сложных бизнес-правил.
Decorator				Расширяет поведение объекта во время выполнения, добавляя или изменяя
(Декоратор)				операции, которые будут осуществляться при обработке запроса. Требует
				общего интерфейса, реализовываемого классами декоратора, которые могут
				объединяться для обработки сложных бизнес-правил.
Dependency Injection				Создает и заполняет члены (поля и свойства) объектов, используя отдельный
(Внедрение				класс, который обычно создает эти зависимости во время выполнения на
зависимостей)				основании конфигурационных файлов. Конфигурационные файлы описывают

	контейнеры, определяющие сопоставление или регистрации типов объектов.
	Сопоставление и регистрация объектов может также выполняться в коде
	приложения. Обеспечивает гибкий подход к изменению поведения и реализации
	сложных бизнес-правил.
Façade (Фасад)	Обеспечивает слабо детализированные операции, унифицирующие результаты,
	поступающие от множества компонентов бизнес-логики. Обычно реализуется
	как удаленный фасад для интерфейсов на основе сообщений бизнес-слоя и
	используется для обеспечения слабого связывания между слоем
	представления и бизнес-слоем.
Factory (Фабрика)	Создает экземпляры объектов без указания конкретного типа. Требует наличия
	объектов, которые реализуют общий интерфейс или расширяют общий базовый
	класс.
Transaction Script	Рекомендуется для базовых CRUD-операций с минимальным набором бизнес-
(Сценарий	правил. Компоненты сценария транзакции также инициируют транзакции. Это
транзакции)	означает, что все операции, осуществляемые компонентом, должны
	представлять неделимую единицу работы. При использовании этого шаблона
	компоненты бизнес-логики взаимодействуют с другими компонентами бизнес-
	слоя и компонентами данных для завершения операции.

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

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

Электронная версия списка используемых источников доступна по адресу http://www.microsoft.com/architectureguide.

Более подробно проектирование компонентов бизнес-слоя рассматривается в статье «Application Architecture for .NET: Designing Applications and Services»

(Архитектура приложений для .NET: проектирование приложений и сервисов) http://msdn.microsoft.com/en-us/library/ms954595.aspx .

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

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

◦«Architecture and Design Review of a .NET Application for Performance and Scalability» (Обзор архитектуры и дизайна .NET-приложения с точки зрения производительности и масштабируемости) по адресу http://msdn.microsoft.com/en-us/library/ms998544.aspx.

◦«Design Guidelines for Application Performance» (Рекомендации по производительности приложений) по адресу http://msdn.microsoft.com/enus/library/ms998541.aspx.

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

◦«Introducing System.Transactions in the .NET Framework 2.0» (Представляем

System.Transactions in the .NET Framework 2.0) по адресу http://msdn.microsoft.com/en-us/library/ms973865.aspx.

◦«Transactions in WCF» (Транзакции в WCF) по адресу http://msdn.microsoft.com/en-us/library/ms730266.aspx.

◦«Transaction Processing in .NET 3.5» (Обработка транзакций в .NET 3.5) по адресу http://msdn.microsoft.com/en-us/library/w97s6fw4.aspx.

Реализация рабочего процесса в компонентах бизнес-слоя более подробно рассматривается в следующих источниках:

◦«Introduction to the Windows Workflow Foundation Rules Engine» (Введение в обработчик правил Windows Workflow Foundation) по адресу http://msdn.microsoft.com/en-us/library/aa480193.aspx.

◦«Windows Workflow Foundation» по адресу http://msdn.microsoft.com/enus/library/ms735967.aspx.