Фаулер М. Архитектура корпоративных программных приложений

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

144 Часть II. Типовые решения

к книге [17]. С проблематикой реляционной модели вас близко познакомит [21]. Чтобы

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

мать объекты на концептуальном уровне. В этом смысле лучше других поможет книга

[29]. Если хотите разобраться с типовыми решениями, примыкающими к модели пред-

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

личного назначения, непременно прочитайте классический труд [20].

ЭрикЭванс (Eric Evans) занимается подготовкой книги [15], специально посвящен-

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

и выглядит она весьма многообещающе.

Пример: определение зачтенного дохода (Java)

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

любые примеры должны быть достаточно просты, чтобы их можно было легко понять; но

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

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

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

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

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

зачтенного дохода.

Сразу замечу, что каждый класс в этом маленьком примере (рис. 9.3) содержит

и функции и данные: например, скромный класс RevenueRecognition обладает двумя

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

class RevenueRecognition...

private Money amount;

private MfDate date;

public RevenueRecognition(Money amount, MfDate date) {

this.amount = amount;

this.date = date; }

public Money getAmountO {

return amount; } boolean

isRecognizableBy(MfDate asOf) {

return asOf.after(date) || asOf.equals(date);

}

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

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

class Contract. . .

private List revenueRecognitions = new ArrayList();

public Money recognizedRevenue(MfDate asOf) { Money

result = Money.dollars(0); Iterator it =

revenueRecognitions.iterator(); while (it.hasNext())

{

RevenueRecognition r = (RevenueRecognition)it.next (); if

(r.isRecognizableBy(asOf))

Глава 9. Представление бизнес-логики 145

result = result.add(r.getAmountО);

}

return result;

}

Рис. 9.3. Диаграмма классов для примера модели предметной области

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

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

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

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

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

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

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

Как видно из диаграммы на рис. 9.3, вычисление зачтенного дохода сопряжено с соз-

данием множества мелких объектов: от "контракта" и "продукта" до иерархии стратегий

определения зачтенного дохода. Типовое решение стратегия (Strategy) [20] — широко из-

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

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

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

146 Часть II. Типовые решения

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

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

class Contract...

private Product product;

private Money revenue;

private MfDate whenSigned;

private Long id;

public Contract(Product product, Money revenue,

MfDate whenSigned) {

this.product = product;

this.revenue = revenue;

this.whenSigned = whenSigned; }

class Product...

private String name;

private RecognitionStrategy recognitionStrategy;

public Product(String name, RecognitionStrategy

recognitionStrategy) { this.name = name;

this.recognitionStrategy = recognitionStrategy; }

public static Product newWordProcessor(String name) {

return new Product(name, new

CompleteRecognitionStrategy() ) ; } public static

Product newSpreadsheet(String name) {

return new Product(name, new ThreeWayRecognitionStrategy(

60,90) ) ; } public static Product newDatabase(String name) {

return new Product(name, new ThreeWayRecognitionStrategy (

30,60) ) ; }

class RecognitionStrategy...

abstract void calculateRevenueRecognitions(Contract

"^contract) ;

class CompleteRecognitionStrategy...

void calculateRevenueRecognitions(Contract contract) {

contract.addRevenueRecognition(new RevenueRecognition(

contract.getRevenue(), contract.getWhenSigned()));

class ThreeWayRecognitionStrategy. . .

private int firstRecognitionOffset;

private int secondRecognitionOffset;

Глава 9. Представление бизнес-логики 147

public ThreeWayRecognitionStrategy(int firstRecognitionOffset, bint

secondRecognitionOffset) {

this.firstRecognitionOffset = firstRecognitionOffset;

this.secondRecognitionOffset = secondRecognitionOffset; }

void calculateRevenueRecognitions(Contract contract) {

Money[] allocation = contract.getRevenue().allocate(3);

contract.addRevenueRecognition(new RevenueRecognition

(allocation[0], contract.getWhenSigned() ) ) ;

contract.addRevenueRecognition(new RevenueRecognition

(allocation[l] ,

contract.getWhenSigned().addDays(firstRecognitionOffset)));

contract.addRevenueRecognition(new RevenueRecognition

(allocation [2] ,

contract.getWhenSigned() .addDays(secondRecognitionOffset) ) ) ; }

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

можности роста приложения. Например, для добавления очередного алгоритма опреде-

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

Метод calculateRevenueRecognitions.

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

объект стратегии. Для тестирования я применяю приведенный ниже код.

class Tester...

private Product word = Product.newWordProcessor(

"Thinking Word");

private Product calc = Product.newSpreadsheet(

"Thinking Calc");

private Product db = Product.newDatabase("Thinking DB");

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

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

class Contract...

public void calculateRecognitions () {

product.calculateRevenueRecognitions(this)

; }

class Product...

void calculateRevenueRecognitions(Contract contract) {

recognitionStrategy.calculateRevenueRecognitions(contract) ; }

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

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

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

рукций. Вы наверняка обратили внимание, что приведенный фрагмент кода вообще

148 Часть II. Типовые решения

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

ния продукта. Модели предметной области особенно хороши, когда существует множест-

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

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

на уровень связей между объектами. Чем более близка логика, тем с большей вероятно-

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

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

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

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

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

той или иной мере сложной задачей. Во-вторых, назначение модели предметной области

во многом состоит в сокрытии базы данных от верхних слоев системы.

Модуль таблицы (Table Module)

Объект, охватывающий логику обработки всех записей хранимой

или виртуальной таблицы базы данных

Одна из ключевых предпосылок объектной модели — сочетание элементов данных

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

нован на концепции объектов с идентификационными признаками в совокупности

с требованиями модели предметной области (Domain Model, 140). Если, например, речь

идет о классе, представляющем сущность "служащий", любой экземпляр класса соот-

ветствует определенному служащему; коль скоро есть ссылка на объект, отвечающий

Глава 9. Представление бизнес-логики 149

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

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

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

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

роль эдаких бедных родственников, с которыми никто не желает иметь дела. Поэтому

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

превращается в прихотливую игру ума.

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

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

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

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

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

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

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

Принцип действия

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

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

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

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

упоминания об идентификационном признаке объекта. Если, скажем, требуется полу-

чить адрес служащего, ДЛЯ ЭТОГО применяется метод anEmployeeModule.GetAddress

(long empioyeeiD). В том случае, когда необходимо выполнить операцию, касающуюся

определенного служащего, соответствующему методу следует передать ссылку на

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

в таблице базы данных.

Модулю таблицы, как правило, отвечает некая табличная структура данных. Подобная

информация обычно является результатом выполнения SQL-запроса и сохраняется в ви-

де множества записей (Record Set, 523). Модуль таблицы предоставляет обширный арсе-

нал методов ее обработки. Объединение функций и данных обеспечивает многие пре-

имущества модели инкапсуляции.

Нередко для решения общей задачи необходимо создать несколько модулей таблицы

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

(рис. 9.4).

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

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

ли таблицы для любых достойных SQL-запросов и виртуальных таблиц.

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

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

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

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

класса. Не исключается и возможность создания иерархии наследования, когда, скажем,

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

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

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

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

базе данных. Альтернативой служит шлюз таблицы данных (Table Data Gateway, 167).

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

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

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

таблицы данных.

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

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

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

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

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

множество записей слою представления для отображения и редактирования информа-

ции средствами графических табличных элементов управления. Последние не "осве-

домлены", откуда поступили данные — непосредственно от реляционной СУБД или от

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

работку. По завершении редактирования информация возвращается модулю таблицы

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

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

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

Слово "таблица" в названии типового решения подчеркивает, что в приложении пре-

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

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

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

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

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

150 Часть II. Типовые решения

Рис. 9.5. Схема взаимодействия слоев кода с модулем таблицы

Назначение

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

данных и потому допускает очевидное применение в ситуациях, где доступ к информа-

ции обеспечивается при посредничестве множеств записей. Структуре данных отводится

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

линейными и эффективными.

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

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

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

укоризненно. Поэтому для реализации особо изощренной логики предпочтительнее

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

между способностью модели предметной области к эффективному отображению биз-

нес-логики и простотой интеграции кода приложения и реляционных структур дан-

ных, обеспечиваемой модулем таблицы.

Если объекты модели предметной области относительно точно отвечают таблицам ба-

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

активной записью (Active Record, 182). Модуль таблицы, однако, ведет себя лучше, чем

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

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

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

множеств записей ситуация, возможно, и изменится.

Глава 9. Представление бизнес-логики 151

152 Часть II. Типовые решения

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

основе архитектуры Microsoft COM. В технологии СОМ (и .NET) множество записей

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

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

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

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

crosoft ADO. В подобных случаях модуль таблицы позволяет описать бизнес-логику в хо-

рошо структурированном виде.

Пример: определение зачтенного дохода (С#)

Настал черед вновь обратиться к задаче определения зачтенного дохода (см. раздел

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

нии зачтенного дохода ("revenue recognitions") по контракту ("contract") в зависимости от

упомянутого в нем типа продукта ("product"). Здесь будем различать три типа продук-

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

значения wp (от word processor) перечислимого типа ProductType), электронная таблица

(ss — spreadsheet) и СУБД (DB — database).

Модуль таблицы основывается на некой структуре данных, обычно реляционной (в

будущем, вероятно, на эту роль сможет претендовать модель XML). В нашем случае ре-

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

Рис. 9.6. Схема базы данных о контрактах, продуктах и зачтенном доходе

Классы, манипулирующие этими данными, следуют единой форме: каждой таблице

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

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

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

ных. Каждый класс модуля таблицы содержит элемент данных системного .NET-типа Da-

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

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

даже супертип слоя (Layer Supertype, 491).

class TableModule...

protected DataTable table;

protected TableModule(DataSet ds, String tableName) {

table = ds.Tables[tableName];

Глава 9. Представление бизнес-логики 153

Конструктор производного класса вызывает конструктор суперкласса и передает на-

именование конкретной таблицы.

class Contract. . .

public Contract(DataSet ds) : base(ds, "Contracts") {}

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

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

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

цификации ADO.NET.

contract = new Contract(dataset) ;

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

"добраться" до определенной записи таблицы данных по значению первичного ключа.

class Contract...

public DataRow this[long key ] {

get {

String filter = String.Format("ID ={0}", key);

return table.Select(filter) [0] ;

Функции первой группы осуществляют вычисление значений зачтенного дохода по

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

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

контрактов, я решил добавить в класс Contract надлежащий метод.

class Contract...

public void CalculateRecognitions(long contractID) {

DataRow contractRow = this[contractID]; Decimal amount

= (Decimal)contractRow["amount"]; RevenueRecognition

rr = new RevenueRecognition( table.DataSet);

Product prod = new Product(table.DataSet);

long prodID = GetProductld(contractID);

if (prod.GetProductType(prodID) == ProductType.WP) {

rr.Insert(contractID, amount, (DateTime)GetWhenSigned(

contractlD) ) ;

} else if (prod.GetProductType(prodID) ==

ProductType.SS) {

Decimal!] allocation = allocate (amount, 3);

rr.Insert(contractID,

allocation[0],(DateTime)GetWhenSigned(contractID));

rr.Insert(contractID, allocation[1], (DateTime)

GetWhenSigned(contractID).AddDays(60));

rr.Insert(contractID, allocation [2], (DateTime)

GetWhenSigned(contractID) .AddDays(90) ) ; } else

if (prod.GetProductType(prodID) == ProductType.DB)

{