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

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

54 Часть I. Обзор

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

меняется совместно с типовым решением множество записей (Record Set, 523). Посылая

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

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

(см. рис. 2.3). Если потребуется выполнять операции над отдельным контрактом, следует

сообщить объекту соответствующий идентификатор (ID).

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

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

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

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

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

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

(скажем, наследование (inheritance), стратегии (strategies) и другие объектно-ориенти-

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

уточнения структуры логики.

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

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

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

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

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

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

для отображения. Некоторые платформы, в частности Microsoft COM и .NET, поддержи-

вают именно такой стиль разработки.

Глава 2. Организация бизнес-логики 55

Выбор типового решения

Итак, какому из трех типовых решений отдать предпочтение? Ответ неочевиден и во

многом зависит от степени сложности бизнес-логики. На рис. 2.4 показан один из тех

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

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

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

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

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

Сложность логики домена

Рис. 2.4. Зависимость стоимости реализации различных схем организации бизнес-логики от ее сложности

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

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

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

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

Конечно, необходимо разобраться, к какому именно сегменту оси х относится кон-

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

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

56 Часть I. Обзор

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

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

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

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

Существует ряд факторов, влияющих на кривизну линий графика. Наличие команды

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

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

(последнее обусловлено сложностью слоя источника данных). Таким образом, чем опыт-

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

области.

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

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

наподобие Visual Studio .NET, где многие средства построены именно на основе модели

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

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

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

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

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

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

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

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

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

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

Три типовых решения, которые мы бегло рассмотрели, не являются взаимоисклю-

чающими альтернативами. На самом деле сценарий транзакции нередко используется для

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

для оставшейся части.

Уровень служб

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

предметной области на два самостоятельных слоя: "поверх" модели предметной области

или модуля таблицы располагается слой служб (Service Layer, 156). Обычно это целесооб-

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

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

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

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

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

Поддерживая внятный интерфейс приложения (API), слой служб подходит также для

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

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

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

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

Основное решение, принимаемое при проектировании слоя служб, состоит в том,

какую часть функций уместно передать в его ведение. Самый "скромный" вариант —

Глава 2. Организация бизнес-логики 57

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

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

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

cases) приложения, и предоставляет удачную возможность включить в код функции-

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

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

сценариев транзакции. Нижележащие объекты домена в этом случае могут быть тривиаль-

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

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

антом слоя источника данных (скажем, активной записью (Active Record, 182)).

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

больше, нежели "смесь" двух подходов: речь идет о модели "контроллер-сущность"

("controller—entity") (ее название обязано своим происхождением одному общеупотреби-

тельному приему, основанному на результатах из [22]). Главная особенность модели за-

ключается в том, что логика, относящаяся к отдельным транзакциям или вариантам ис-

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

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

троллеров в типовых решениях модель-представление-контроллер (Model View Controller,

347) и контроллер приложения (Application Controller, 397) (вы познакомитесь с ними поз-

же) и поэтому называются также контроллерами вариантов использования (use case control-

ler). Функции, характерные одновременно для нескольких вариантов использования, пе-

редаются объектам-сущностям (entities) домена.

Хотя модель "контроллер—сущность" распространена довольно широко, я отношусь

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

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

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

безны произнести и "б", отведя этому решению доминирующую роль. Единственное

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

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

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

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

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

вующего приложения).

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

держащие бизнес-логику; просто я хочу подчеркнуть, что создавать на их основе фикси-

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

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

мере необходимости, а не в виде архитектурного слоя.

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

только возможен (если он вообще нужен). Обычно же я добавляю его только тогда, когда

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

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

этим моим советом вы можете благополучно пренебречь. Рэнди Стаффорд (Randy Staf-

ford) добился впечатляющих успехов на ниве проектирования программного обеспече-

ния, используя модели с "богатым" слоем служб, поэтому я и попросил его написать од-

ноименный раздел этой книги.

Глава 3

Объектные модели и

реляционные базы

данных

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

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

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

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

массивы данных все еще хранятся в устаревших форматах (скажем, в файлах ISAM

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

вающих связь с системами баз данных, ориентируются на реляционные СУБД.

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

ими SQL — наиболее стандартизованного языка коммуникаций с базой данных. Хотя

сегодня SQL все более обрастает раздражающе несовместимыми и сложными "улучше-

ниями", поддерживаемыми различными поставщиками СУБД, синтаксис ядра языка,

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

Архитектурные решения

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

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

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

или даже невозможно. Поэтому он заслуживает наиболее тщательного осмысления.

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

бизнес-логики.

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

SQL сопряжено с определенными трудностями. Многие разработчики просто не владеют

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

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

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

60 Часть I. Обзор

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

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

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

ность их оптимизировать.

По этим причинам разумнее обособить код SQL от бизнес-логики, разместив его в

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

ровании" структуры каждой таблицы базы данных в отдельном классе, который форми-

рует шлюз (Gateway, 483), поддерживающий возможности обращения к таблице. Теперь

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

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

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

шлюз. Наиболее очевидный — создание экземпляра шлюза для каждой записи, возвра-

щаемой в результате обработки запроса к базе данных (рис. 3.1). Подобный шлюз записи

данных (Row Data Gateway, 175) представляет собой модель, естественным образом ото-

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

Рис. 3.1. Для каждой записи, возвращаемой запросом,

создается экземпляр шлюза записи данных

Во многих средах поддерживается модель множества записей (Record Set, 523) — одна

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

содержимого базы данных. Инструментальными системами предлагаются даже графиче-

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

цей базы данных следует сопоставить соответствующий объект типа шлюз таблицы данных

(Table Data Gateway, 167) (рис. 3.2), который содержит методы активизации запросов,

возвращающих множество записей.

Рис. З.2. Для каждой таблицы в базе данных создается

экземпляр шлюза таблицы данных

Глава 3. Объектные модели и реляционные базы данных 61

Я склоняюсь к необходимости применения какого-либо из "шлюзовых" решений да-

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

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

четкого разделения кода SQL и бизнес-логики.

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

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

лицы (Table Module, 148). Это типовое решение следует иметь в виду и при работе с хра-

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

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

В подобной ситуации, определяя шлюз таблицы данных для каждой таблицы, следует

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

ти еще и дополнительный шлюз таблицы данных, выполняющий функцию оболочки, ко-

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

При использовании модели предметной области (Domain Model, 140) возникают другие

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

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

не вполне целенаправленными или просто несостоятельными.

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

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

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

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

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

пись (Active Record, 182) (рис. 3.3). Это решение можно воспринимать и так, будто, начав

со шлюза записи данных, мы добавили в класс порцию бизнес-логики (может быть, когда

обнаружили в нескольких сценариях транзакции (Transaction Script, 133) повторяющиеся

фрагменты кода).

Рис. 3.3. При использовании решения активная запись объект класса домена

"осведомлен"о том, как взаимодействовать с таблицами базы данных

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

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

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

решения типа активная запись начинают сдавать свои позиции. При разнесении бизнес-

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

домена и таблицами базы данных постепенно теряется. Реляционные базы данных не

поддерживают механизм наследования, что затрудняет применение стратегий (strategies)

[20] и других развитых объектно-ориентированных типовых решений. А когда бизнес-

62 Часть I. Обзор

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

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

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

вать промежуточные функциональные уровни. Так, решение типа шлюза способно уст-

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

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

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

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

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

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

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

(Data Mapper, 187) (рис. 3.4) обслуживает все операции загрузки и сохранения информа-

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

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

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

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

слоев.

Рис. 3.4. Преобразователь данных изолирует объекты домена от базы данных

Я не рекомендовал бы рассматривать шлюз в качестве основного механизма сохране-

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

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

ной альтернативой окажется типовое решение активная запись. Если же вам приходится

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

образователь данных.

Рассмотренные типовые решения нельзя считать взаимоисключающими. В большин-

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

в базе данных. Для этого придется выбрать одно из перечисленных решений — смешение

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

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

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

Здесь и ниже, употребляя слово таблица (table), я имею в виду, что обсуждаемые

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

ным характером: к хранимым процедурам (storedprocedures), представлениям (views), а так-

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

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

нятия, отсутствует. (Под представлением я подразумеваю виртуальную таблицу (virtual ta-

ble) — то же толкование принято и в SQL; запросы к обычным и виртуальным таблицам

обладают одним и тем же синтаксисом.)

Глава 3. Объектные модели и реляционные базы данных 63

Операции обновления (update) содержимого источников, не являющихся хранимыми

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

модифицировать напрямую — вместо этого приходится манипулировать таблицами, на

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

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

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

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

Впрочем, проблемы все еще остаются. Непонимание природы формирования вирту-

альных таблиц приводит к несогласованности операций: если последовательно выпол-

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

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

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

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

придется заплатить?

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

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

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

реляционной и объектной моделями; это послужило стимулом создания объектно-

ориентированных СУБД, расширяющих парадигму до аспектов сохранения информации

об объектах на дисках. При работе с объектно-ориентированной базой данных вам не

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

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

нять, "беспокоится" СУБД. Помимо того, с помощью механизма транзакций вы вправе

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

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

ектов, размещенных в оперативной памяти.

Главное преимущество объектно-ориентированных баз данных — повышение произ-

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

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

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

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

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

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

ния не находят, и основная причина такого положения вещей — риск. За реляционными

СУБД стоят тщательно разработанные, хорошо знакомые и проверенные жизнью техно-

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

жении длительного времени. SQL представляет собой в достаточной мере унифициро-

ванный интерфейс для разнообразных инструментальных средств. (Если вас заботят

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

предусматривающих необходимость взаимодействия с СУБД, я могу сказать только

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

изводительности объектно-ориентированных и реляционных систем я не знаком.)

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

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

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

структуры. Хотя рассмофенные в этой книге типовые решения сообщат вам многое из