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

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

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

Платформы и инструменты

На страницах этой книги я все время пытаюсь продемонстрировать опыт выполнения

проектов на множестве различных платформ. Навыки работы с Forte, CORBA и Smalltalk

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

я уделяю повышенное внимание средам Java и .NET, связана с тем, что они, по обшему

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

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

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

Python и Ruby, и потому необходимо дать им шанс.)

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

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

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

написаны в начале 2002 года.

Java и J2EE

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

ной следует считать компонентную модель Enterprise Java Beans. После многочисленных

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

цертов группы The Who) спецификация EJB 2.0 наконец увидела свет. Но для конструи-

рования хорошего J2EE-npwioxeHM применять компоненты EJB вовсе не обязательно,

что бы вам ни говорили их поставщики. Вполне можно обойтись моделью POJO (Plain

Old Java Objects) в сочетании с JDBC.

Проектные альтернативы для платформы J2EE варьируются в зависимости от приме-

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

логики.

Если поверх некоторого шлюза (Gateway, 483) функционирует сценарий транзакции

(Transaction Script, 133), общеупотребительным подходом, связанным с технологией EJB,

в настоящий момент является такой: реализовать сценарий транзакции на основе компо-

нентов сеанса (session beans), а компоненты сущностей (entity beans) использовать как шлюз

записи данных (Row Data Gateway, 175). Если бизнес-логика достаточно проста, такую ар-

хитектуру следует считать наиболее разумной. Существует и одна проблема: от сервера

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

ским (или финансовым) причинам. Подход "без EJB" — это объекты POJO для сценария

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

Data Gateway, 167). Если более приемлемы множества записей формата JDBC 2.0, это по-

вод для использования их в виде множеств записей (Record Set, 523) в контексте шлюза

таблицы данных. Если вы еще не приняли окончательного решения о необходимости ис-

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

интерфейса удаленного доступа (Remote Facade, 405) к компонентам сущностей.

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

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

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

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

записи (Active Record, 182). Также неплохо окружать компоненты сущностей оболочками

Глава 8. Общая картина 125

в виде компонентов сеанса, действующих как интерфейсы удаленного доступа. Если, од-

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

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

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

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

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

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

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

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

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

телей данных (Data Mapper, 187) — либо с привлечением неких готовых инструментов

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

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

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

интерфейсами. Я не вижу смысла в таких компонентах. Компоненты сущностей обычно

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

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

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

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

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

(Единственное известное мне исключение — это типовое решение составная сущность

(Composite Entity), описанное в [3], которое представляет альтернативный способ исполь-

зования компонентов сущностей и, откровенно говоря, мне не очень нравится.)

На данный момент типовое решение модуль таблицы (Table Module, 148) не завоевало

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

множество записей формата JDBC окружить дополнительными службами; тогда реше-

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

подошла бы модель POJO; кроме того, можно было бы заключить модуль таблицы в обо-

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

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

.NET

Если присмотреться к .NET, Visual Studio и к истории развития инструментальных

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

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

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

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

ми преимуществами вездесущей модели множества записей.

Итак, решение модуль таблицы на платформе Microsoft трактуется как выбор, пред-

лагаемый по умолчанию. В самом деле, весомых причин для применения сценариев

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

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

Впрочем, это не значит, что можно слепо отказаться от модели предметной области.

В .NET удается конструировать модели предметной области так же легко, как и в любой

другой объектно-ориентированной среде. Однако в этом случае от инструментов разра-

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

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

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

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

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

Сейчас горячей темой в .NET является все, что имеет отношение к Web-службам.

Но не стоит пользоваться Web-службами внутри приложения; лучше обращаться к ним,

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

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

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

данном случае вряд ли оправданно.

Хранимые процедуры

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

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

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

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

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

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

определенной степени связываете себя с конкретным поставщиком СУБД. (Удачным

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

выполнять Java-приложения в контексте процесса СУБД; это равнозначно размещению

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

ставщика СУБД все еще сохраняется, но зато исключаются затраты на перенос кода.)

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

жащих инструментов их структуризации многие разработчики просто избегают их ис-

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

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

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

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

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

приложения, трактуя принятое решение как оптимизационное, а не архитектурное.

(В [30] приведены и другие аргументы в пользу более широкого применения аппарата

хранимых процедур.)

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

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

каких-то собственных сложившихся убеждений. Могу сказать одно: я предпочитаю изо-

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

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

диционных конструкций SQL.

Web-службы

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

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

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

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

риваемых типовых решений Web-службам отводится всего лишь вспомогательная роль:

Глава 8. Общая картина 127

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

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

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

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

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

"чрезвычайной простоте" Web-служб не заставили вас забыть Первый Закон Распределе-

ния Объектов (см. главу 7, стр. 113).

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

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

более предпочтительной асинхронная модель, основанная на сообщениях. У меня нет

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

даю их появления уже в ближайшие несколько лет.

Другие модели слоев

Мое изложение строится на основе модели трех слоев, но это отнюдь не единственная

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

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

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

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

Прежде всего рассмотрим так называемую модель Брауна [9]. Модель охватывает пять

слоев: представление, контроллер/медиатор, домен (предметная область, бизнес-логика),

отображение данных и источник данных (табл. 8.1). Два дополнительных слоя, по сущест-

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

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

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

Таблица 8.1. Слои по Брауну

Браун Фаулер

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

Контроллер/медиатор Представление (контроллер приложения —

Application Controller, 397)

Домен Домен

Отображение данных Источник данных (преобразователь данных —

Data Mapper, 187)

Источник данных Источник данных

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

им отводится роль типовых решений: так, контроллер приложения — это посредник меж-

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

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

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

"Типовые решения, предназначенные для представления данных в Web", а преобразова-

тель данных описан в главе 10, "Архитектурные типовые решения источников данных".

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

жит воспринимать только как факультативное проектное решение. Я исповедую сле-

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

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

функций.

Хорошая схема расслоения кода приложений на платформе J2EE реализована в виде

набора типовых решений Core J2EE [3]. Здесь различаются следующие слои: клиент,

представление, бизнес, интеграция и ресурсы (табл. 8.2). Для слоев бизнеса и интефации

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

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

ем нашего слоя представления на две части между клиентом (слой клиента) и сервером

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

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

Таблица 8.2. Слои Core J2EE

Core J2EE Фаулер

Клиент Часть слоя представления, функционирующая в контексте

клиента (например, в системах с толстыми клиентами)

Представление Часть слоя представления, функционирующая на сервере

(например, обработчики HTTP, страницы сервера)

Бизнес Домен

Интеграция Источник данных

Ресурсы Внешние ресурсы, к которым обращается источник данных

В архитектуре Microsoft DNA [24] различают три слоя — представление, бизнес и доступ

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

(табл. 8.3). Наибольшее отличие состоит в способе передачи информации от слоя доступа

к данным. В Microsoft DNA все слои имеют дело с множествами записей, возвращаемы-

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

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

нии базы данных.

Таблица 8.3. Слои Microsoft DNA

Microsoft DNA Фаулер

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

Бизнес Домен

Доступ кданным Источник данных

Глава 8. Общая картина 129

Это можно объяснить следующим образом: множество записей DNA действует как

объект переноса данных (Data Transfer Object, 419) между слоями. Слой бизнеса способен

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

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

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

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

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

слоя бизнеса.

Слой домена в этом случае структурируется в форме модулей таблицы (Table Mo-

dule, 148), а источник данных приобретает вид шлюзов таблицы данных (Table Data

Gateway, 167).

Схема Маринеску [28] содержит пять слоев (табл. 8.4). Слой представления расщеплен

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

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

слой служб (Service Layer, 156), что соответствует обычной практике деления бизнес-

логики на две части. Это общий подход, подкрепленный ограничениями модели EJB как

модели предметной области (за подробностями обращайтесь к с. 140).

Таблица 8.4. Слои по Маринеску

Маринеску Фаулер

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

Приложение Представление (контроллер приложения)

Службы Домен (слой служб)

Домен Домен (модель предметной области)

Сохранение данных Источник данных

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

полагающем возможность отмежевания логики процесса от "чистой" бизнес-логики.

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

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

(например, с помощью механизма сообщений). Стоит ли иметь отдельные слои служб и

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

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

мые мною коллеги эту точку зрения не разделяют.

В [30] предложена самая сложная схема расслоения программной системы (табл. 8.5).

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

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

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

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

кой подход совершенно оправдан и полезен. Слои хранимых процедур Нильссона содер-

жат как источники данных, так и бизнес-логику.

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

Таблица 8.5. Слои по Нильссону

Нильссон Фаулер

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

Представление (контроллер приложения) Приложение Домен (слой

служб) Домен Домен (модель предметной области) Доступ к

хранимым данным Источник данных Общедоступные хранимые процедуры

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

Источник данных (возможно, с частью бизнес-логики)

Как и Маринеску, для описания бизнес-логики Нильссон использует отдельные слои

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

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

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

ЧАСТЬ II

Типовые решения

Глава 9

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

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

Сценарий транзакции (Transaction Script)

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

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

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

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

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

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

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

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

Сценарий транзакции организует логику вычислительного процесса преимущест-

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

посредничестве кода тонкой оболочки. Каждой транзакции ставится в соответствие

собственный сценарий транзакции (общие подзадачи могут быть вынесены в подчи-

ненные процедуры).

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

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

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

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

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

мы оплаты и фиксации заказа в базе данных.