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

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

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

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

кода SQL из бизнес-логики применяется шлюз записи данных (Row Data Gateway, 175)

или шлюз таблицы данных (Table Data Gateway, 167).

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

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

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

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

онных структур обеспечивает преобразователь данных (Data Mapper, 187), но это типовое

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

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

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

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

реализуется в течение короткого итеративного цикла. Провести шесть месяцев за по-

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

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

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

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

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

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

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

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

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

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

интегрировать каждую ее часть в базу данных.

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

тернативы, но процесс несколько отличается. Если бизнес-логика проста, ее слой распо-

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

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

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

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

ния в существующей базе данных.

Двойное отображение

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

дится взаимодействовать с несколькими источниками. Это могут быть базы данных с

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

(следует заметить: чем меньше и тоньше различия, тем сильнее головная боль), а также

совершенно иные формы существования информации (например, комбинация XML-

документов, CICS-транзакций и реляционных таблиц).

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

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

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

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

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

ках. На втором этапе логическая схема отображается в физические с учетом их частных

особенностей.

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

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

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

физическую можно воспринимать в виде шлюза (Gateway, 483), а для перехода от формы

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

бражения.

Использование метаданных

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

хо продуманной структуры. Общие функции можно вынести "за скобки", например

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

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

связанный с отображением метаданных (Metadata Mapping, 325).

Типовое решение отображение метаданных основано на вынесении функций ото-

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

данных и полями объектов. Наличие метаданных позволяет не повторять код отобра-

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

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

большой объем информации.

<fieldName = "customer", targetClass = "Customer",

^dbColumn = "custID", targetTable = "customers",

'blowerBound = "1", upperBound = "1", setter = "loadCustomer"/>

С помощью этой информации вам удастся определить операции считывания и за-

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

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

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

онных структур.

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

сов в терминах прикладных объектов. Типовое решение объект запроса (Query Object,

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

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

таданных для трансляции таких выражений в соответствующие конструкции SQL.

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

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

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

екты запроса в контексте хранилища: в этой ситуации разработчику приложения неве-

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

лище весьма удачно сочетается с богатыми моделями предметной области (Domain

Model, 140).

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

Соединение с базой данных

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

честве некоторого объекта соединения (connection). Прежде чем выполнять команды и

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

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

данных. По завершении обслуживания запроса возвращается объект типа множество за-

писей (Record Set, 523). Некоторые интерфейсы позволяют манипулировать полученным

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

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

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

открытым, как минимум, до завершения транзакции.

Во многих средах открытие выделенного соединения сопряжено с расходованием

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

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

а запрашивает его из пула и освобождает, когда оно больше не требуется. Сегодня под-

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

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

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

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

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

ние соединения из пула.

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

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

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

выглядят совершенно идентично. Аналогично, закрытие соединения в реальности может

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

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

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

они могут означать соответственно "захват" соединения из пула и его "освобождение" с

возвращением в пул.

Неважно, как создаются соединения, но ими необходимо надлежащим образом

управлять. Поскольку, как уже отмечалось, речь в данном случае идет о дорогостоящих

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

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

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

средничестве одного и того же объекта соединения.

Наиболее общая рекомендация такова: следует запросить объект соединения явно,

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

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

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

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

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

манду в виде явно задаваемого параметра. К сожалению, при этом может оказаться, что

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

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

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

В этой ситуации целесообразно вспомнить о реестре (Registry, 495). Поскольку вам на-

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

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

Даже если вы не так забывчивы, как я, то и в этом случае согласитесь, что требование

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

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

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

транзакции приведет к ее откату.

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

жит возвращать системе сразу по завершении их использования. В современных средах

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ления ими состоит в трактовке соединения как неотъемлемого "атрибута" транзакции:

оно открывается в начале транзакции и закрывается по завершении операций фиксации

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

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

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

шение соединения, вы вряд ли забудете ее зафиксировать (а если и забудете, то, поверьте

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

циями и соединениями демонстрируется в типовом решении единица работы (Unit of

Work, 205).

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

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

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

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

зации пула соединений.

При необходимости обработки данных в автономном режиме в контексте множест-

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

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

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

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

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

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

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

матике управления параллельными заданиями, посвящена глава 5, "Управление па-

раллельными заданиями".

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

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

Другие проблемы

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

запросов вида select * from, а в отдельных случаях предложения select содержат

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

кой выражений select *, особенно при добавлении новых столбцов или перестановке

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

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

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

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

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

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

еще нужно установить опытным путем.

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

ращения соответствуют SQL-определениям соответствующих таблиц. При работе со

шлюзом таблицы данных (Table Data Gateway, 167) следует использовать наименования

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

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

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

и реляционными схемами.

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

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

которые всякий раз приходится компилировать заново. В большинстве СУБД те или

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

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

SQL-запросов.

Многие СУБД поддерживают пакетное выполнение команд SQL. В примерах эти

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

Как именно — зависит от характеристик конкретной платформы.

В примерах объекты соединений заменены объектом "DB" типа реестр (Registry, 495).

Технология создания соединения во многом определяется спецификой СУБД и среды

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

И еще. Ни в одном из типовых решений, кроме тех, которые относятся к сфере управле-

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

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

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

Дополнительные источники информации

С необходимостью отображения объектов в реляционные структуры сталкиваются

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

вительно, что этому предмету посвящено море литературы. Удивительно как раз дру-

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

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

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

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

обобрали до нитки, присутствуют [4, 10, 23, 41]. Настоятельно рекомендую проштуди-

ровать названные работы и вам — они станут хорошим дополнением к материалу этой

книги.

Глава 4

Представление данных в

Web

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

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

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

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

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

Разработка Web-приложения начинается с настройки программного обеспечения

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

щего, какие адреса URL (Uniform Resource Locators— URLs) обслуживаются теми или

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

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

Функции Web-сервера состоят в интерпретации адреса URL запроса и передаче управле-

ния соответствующей программе. Существует две основные формы представления про-

граммы Web-сервера — сценарий (script) и страница сервера (serverpage).

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

HTTP. Типичными примерами могут служить сценарии CGI и сервлеты Java. Подобная

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

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

лучает данные с Web-страницы, проверяя строковый объект HTTP-запроса и вычленяя из

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

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

риев CGI. В иных случаях, например при использовании сервлетов Java, профаммист по-

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

значительно удобнее. Результатом работы Web-сервера служит другая — ответная —

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

Задача формирования кода HTML посредством команд поточного вывода не очень

привлекательна для профаммистов, а непрофаммистам она вообще не по силам, хотя

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

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

дятся к возврату порции текстовых данных. Страница содержит текст HTML с "вкрап-

лениями" исполняемого кода. Подобный подход, реализуемый, например, в PHP, ASP

и JSP, особенно удобен, если требуется незначительная дополнительная обработка текста

с учетом реакции пользователя.

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

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

страниц сервера — для форматирования ответов, вполне разумно применять их совмест-

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

интерфейсах на основе типового решения модель-представление-контроллер (Model View

Controller, 347), пример которого представлен на рис. 4.1.

Решение находит широкое применение, но зачастую трактуется неверно (это особен-

но характерно для приложений, написанных до появления Web). Основная причина со-

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

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

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

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

(input controller).

Входной контроллер принимает запрос и извлекает из него информацию. Затем он

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

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

формации, необходимой для ответа. По завершении функций он передает управление

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

ние о выборе варианта представления ответа. Управление и соответствующие данные

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

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

объекта HTTP-сеанса, который служит для передачи данных в обоих направлениях.

Основной довод в пользу применения решения модель—представление—контроллер со-

стоит в том, что оно предусматривает полное отмежевание модели от Web-представления.

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

лений. А размещение логики в отдельных объектах сценария транзакции (Transaction

Script, 133) и модели предметной области (Domain Model, 140) облегчает их тестирование.

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

Здесь наступает черед практического применения второго варианта толкования термина

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

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

(Application Controller, 397), назначением которого является управление потоком функций

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

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

уровнями представления и предметной области. Контроллеры приложения могут быть реа-

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

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

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

навигации, но особенно хороша, если представления обладают разной логикой.

Контроллеры приложения нужны далеко не всем системам. Они удобны, когда при-

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

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

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

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

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

применять контроллеры приложения: если потоком функций системы управляет машина,

ответ положителен, а если пользователь — отрицателен.

Рис. 4.1. Укрупненная диаграмма последовательностей, иллюстрирующая взаимодействие модели, представления и входного

контроллера в структуре Web-сервера: контроллер обрабатывает запрос, инициирует реализацию бизнес-логики и передает

управление представлению для формирования ответа, основанного на модели