Организация бизнес-логики

Рассматривая структуру логики предметной области (или бизнес-логики) приложения, отметим, что варианты распределения множества предусматриваемых ею функций могут рассматриваться по трем типовым решениям: сценарий транзакции (Transaction Script), модель предметной области (Domain Model) и модуль таблицы (Table Module).

Простейший подход к описанию бизнес-логики связан с использованием сценария транзакции — процедуры, которая получает на вход информацию от слоя представления, обрабатывает ее, проводя необходимые проверки и вычисления, сохраняет в базе данных и активизирует операции других систем. Затем процедура возвращает слою представления определенные данные, возможно, осуществляя вспомогательные операции для форматирования содержимого результата. Бизнес-логика в этом случае описывается набором процедур, по одной на каждую (составную) операцию, которую способно выполнять приложение. Типовое решение сценарий транзакции, таким образом, можно трактовать как сценарий действия, или бизнес-транзакцию. Оно не обязательно должно представлять собой единый фрагмент кода. Код делится на подпрограммы, которые распределяются между различными сценариями транзакции.

Типовое решение сценарий транзакции отличается следующими преимуществами:

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

• удачно сочетается с простыми схемами организации слоя источника данных на основе типовых решений шлюз записи данных (Row Data Gateway) и шлюз таблицы данных (Table Data Gateway);

• определяет четкие границы транзакции.

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

Конечно, сложная логика — это удачный повод вспомнить об объектах, и объектноориентированный вариант решения проблемы связан с использованием модели предметной области, которая, по меньшей мере в первом приближении, структурируется преимущественно вокруг основных сущностей рассматриваемого домена. Так, например, в лизинговой системе следовало бы создать классы, представляющие сущности «аренда», «имущество», «договор» и т.д., и предусмотреть логику проверок и вычислений: так, например, объект, представляющий сущность «имущество», вероятно, уместно снабдить логикой вычисления стоимости.

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

Рассмотрим простой пример, позволяющий увидеть различие между двумя рассматриваемыми подходами. Простейший способ состоит в сопоставлении диаграмм последовательностей (sequence diagrams), соответствующих обоим вариантам решения одной проблемы (рис. 2.1 и 2.2).

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

Из рис. 2.1 видно, что все обязанности возлагаются на метод сценария транзакции, получающий данные от объектов типа шлюз таблицы данных. На рис. 2.2 показано, напротив, несколько объектов, каждый из которых несет ответственность за выполнение своей доли функций, а результат генерируется объектом «Стратегия определения зачтенного дохода».

Ценность модели предметной области состоит в том, что, освоившись с подходом, вы получаете в свое распоряжение множество приемов, позволяющих поладить с возрастающей сложностью бизнес-логики «цивилизованным» путем. Например, с увеличением количества алгоритмов расчета дохода достаточно создавать новые объекты «Стратегия определения зачтенного дохода». При использовании сценария транзакции в аналогичной ситуации пришлось бы добавлять в логику метода дополнительные условия.

Рис. 2.1. Вычисление зачтенного дохода с помощью сценария транзакции

Рис. 2.2. Вычисление зачтенного дохода с помощью модели предметной области

Существует и третий вариант структуризации бизнес-логики, предусматривающий применение типового решения модуль таблицы; он показан на рис. 2.3.

На первый взгляд это типовое решение очень похоже на модель предметной области: в обоих случаях создаются отдельные классы, представляющие контракт, продукт и зачтенный доход. Принципиальное различие заключается в том, что модель предметной области содержит по одному объекту контракта для каждого контракта, зафиксированного в базе данных, а модуль таблицы является единственным объектом. Модуль таблицы применяется совместно с типовым решением множество записей (Record Set). Посылая запросы к базе данных, пользователь прежде всего формирует объект множество записей, а затем создает объект контракта, передавая ему множество записей в качестве аргумента (см. рис. 2.3). Если потребуется выполнять операции над отдельным контрактом, следует сообщить объекту соответствующий идентификатор (ID).

Рис. 2.З. Вычисление зачтенного дохода с помощью модуля таблицы

Модуль таблицы во многих смыслах представляет собой промежуточный вариант, компромиссный по отношению к сценарию транзакции и модели предметной области. Организация бизнес-логики вокруг таблиц, а не в виде прямолинейных процедур облегчает структурирование и возможность поиска и удаления повторяющихся фрагментов кода. Однако решение модуль таблицы не позволяет использовать многие технологии (скажем, наследование (inheritance), стратегии (strategies) и другие объектно-ориентированные типовые решения), которые применяются в модели предметной области для уточнения структуры логики.

Наибольшее преимущество модуля таблицы состоит в том, как это решение сочетается с остальными аспектами архитектуры. Многие графические интерфейсные среды позволяют работать с результатами обработки SQL-запроса, организованными в виде множества записей. Поскольку решение модуль таблицы также основано на использовании множества записей, открывается возможность выполнения запроса, манипулирования его результатом в контексте модуля таблицы и передачи данных графическому интерфейсу для отображения. Некоторые платформы, в частности Microsoft COM и .NET, поддерживают именно такой стиль разработки.