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

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

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

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

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

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

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

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

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

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

ра можно привести объекты DataSet библиотеки ADO.NET и объекты RowSet библио-

теки JDBC 2.0.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ванных языках сценариев.

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

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

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

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

Transfer Object, 419).

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

новление множества записей? Все больше и больше платформ реализуют множество за-

писей в виде единицы работы (Unit of Work, 205), благодаря чему все изменения множе-

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

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

тономной блокировкой (Optimistic Offline Lock, 434), чтобы проверить параллельные тран-

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

изменения в базу данных.

Явный интерфейс

Большинство реализаций множества записей используют неявный интерфейс (implicit

interface). В этом случае, чтобы извлечь из множества записей требующиеся сведения, не-

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

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

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

tion ["passenger"]. Применение явного интерфейса требует реализации отдельного

Глава 18. Базовые типовые решения 525

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

пассажире выполняется с помощью выражений типа aReservation. passenger.

Неявные интерфейсы обладают чрезвычайной гибкостью. Универсальное множест-

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

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

записей. Несмотря на подобные преимущества, я считаю неявные интерфейсы Очень

Плохим Решением. Как я узнаю, какое слово нужно использовать для того, чтобы доб-

раться к сведениям о пассажире, забронировавшем билет, — "passenger" ("пассажир"),

"guest" ("клиент") или, может быть, "flyer" ("летящий")? Единственное, что я могу сде-

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

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

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

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

программирования. Чтобы узнать фамилию пассажира, забронировавшего билет, мне

Придется Прибегнуть К Кошмарному выражению ВИДа ( (Person) aReservation

[ "passenger" ]) . lastName. Поскольку компилятор утрачивает всю информацию о ти-

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

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

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

aReservation.passenger.lastName.

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

ного приема передачи данных с использованием словарей). Я не приветствую примене-

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

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

столбцам таблицы базы данных. Более того, имена столбцов фигурируют в SQL-

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

нюдь не так сложно, как кажется на первый взгляд.

Как бы там ни было, явные интерфейсы все-таки предпочтительнее. В библиотеке

ADO.NET возможность применения явного интерфейса обеспечивают строго типизиро-

ванные объекты DataSet — сгенерированные классы, которые предоставляют явный и

полностью типизированный интерфейс к множеству записей. Поскольку объект DataSet

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

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

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

нове определений схем XML (XML Schema Definition — XSD).

В настоящее время более распространены неявные интерфейсы, поэтому в примерах

данной книги я использовал нетипизированные объекты DataSet. Несмотря на это, для

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

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

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

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

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

Назначение

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

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

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

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

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

логики домена следует применять модуль таблицы (Table Module, 148): извлеките множе-

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

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

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

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

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

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

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

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

Причиной этому стало широкое распространение языка XML и появление языка запро-

сов XPath, и я думаю, что в будущем на рынке программного обеспечения появится мно-

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

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

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

добие

универсальной структуры данных (Generic Data Structure).

Впрочем, я оставлю раз-

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

Список основных

источников информации

1. Alexander et al. A Pattern Language — Oxford, 1977.

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

продвижении концепции типовых решений. Я не так восхищаюсь этой

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

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

большому количеству идей.

2. Alpert, Brown, and Woolf. Design Patterns Smalltalk Companion. — Addison-

Wesley, 1998.

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

Smalltalk, эта книга расширяет и разъясняет целый ряд классических типо-

вых решений.

3. Alur, Crupi, and Malks. Core J2EE Patterns: Best Practices and Design Strategies. —

Prentice Hall, 2001.

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

Хотя описанные в ней типовые решения разработаны специально для

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

4. http://www. ambysoft. com/mappingObjects. html

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

5. Beck. Extreme Programming Explained. — Addison-Wesley, 2000. (Бек, К. Экстремаль

ное программирование. Библиотека программиста.: Пер. с англ.— СПб.: Питер,

2002.)

Альфа и омега экстремального программирования. Эту книгу должен про-

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

6. Beck. Smalltalk Best Practice Patterns. — Prentice Hall, 1997.

Слово "Smalltalk" в названии этой книги отпугивает многих потенциальных

читателей, и совершенно напрасно. Она содержит больше хороших советов

по объектно-ориентированным языкам программирования, чем многие

528 Список основных источников информации

книги, написанные специально для этих целей. Данный шедевр имеет

единственный недостаток: после того как он прочитан, становится ясно,

как много мы теряем, не программируя на Smalltalk.

7. Beck. Test-Driven Development: By Example. — Addison-Wesley, 2003.

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

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

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

8. Bernstein and Newcomer. Principles of Transaction Processing. — Morgan Kaufmann, 1997.

Отличное введение в загадочный мир транзакций.

9. Brown et al. Enterprise Java Programming with IBM Websphere. — Addison-Wesley, 2001.

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

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

ших советов по проектированию, чем многие толстенные тома, целиком

посвященные этой теме.

10. http://members.aol.com/kgbl001001/Chasms.htm

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

реляционному отображению.

11. Cockburn. Writing Effective Use Cases. — Addison-Wesley, 2001.

Один из лучших справочников по вариантам использования.

12. Cockburn. Prioritizing Forces in Software Design. — In: Pattern Languages of Program

Design 2/Vlissides, Coplien, and Keith (eds.). —Addison-Wesley, 1996.

Дискуссия на тему границ приложения.

13. Coleman, Arnold, and Bodorf. Object-Oriented Development: The Fusion Method, Second

Edition. — Prentice Hall, 2001.

Книга была написана еще до появления UML, а потому сегодня большая

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

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

ся разработчикам слоя служб.

14. http://martinfowler.com/apsupp/spec.pdf

Описание типового решения спецификация (Specification).

15. Evans. Domain-Driven Design: Tackling Complexity in the Heart of Software. — Addison-

Wesley, 2004.

Книга посвящена разработке моделей предметной области — одному из са-

мых важных и самых сложных аспектов разработки корпоративных прило-

жений.

Список основных источников информации 529

16. http://martinfowler.com/ap2/timeNarrative.html

Типовые решения для сохранения истории объектов, состояние которых

меняется с течением времени.

17. Fowler. Analysis Patterns. — Addison-Wesley, 1997.

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

18. Fowler. Refactoring. — Addison-Wesley, 1999.

Метод улучшения структуры существующего кода.

19. http://martinfowler.com/articles/continuouslntegration.html

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

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

20. Gamma, Helm, Johnson, and Vlissides. Design Patterns. — Addison-Wesley, 1995.

(Гамма Э., Хелм Р., Джонсон Р., Влиссидес Д. Приемы объектно-ориентирован

ного программирования. Паттерны проектирования. — СПб.: Питер, 2003.)

Знаменитая книга о типовых решениях с множеством конструктивных

идей.

21. Hay. Data Model Patterns. — Dorset House, 1995.

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

реляционной точки зрения.

22. Jacobson et al. Object-Oriented Software Engineering. — Addison-Wesley, 1992.

Одна из первых книг по объектно-ориентированному проектированию. Со-

держит описание вариантов использования модели "интерфейс—

контроллер-сущность" и подхода к проектированию с ее применением.

23. http://www.objectarchitects.de/ObjectArchitects/orpattems/index.htm

Чудесный источник по объектно-реляционному отображению.

24. Kirtland. Designing Component-Based Applications. — Microsoft Press, 1998.

Описание архитектуры Windows DNA (Distributed interNet Architecture).

25. Knight and Dai. Objects and the Web // IEEE Software. - March/April 2002.

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

лер", ее формированию и использованию в Web-приложениях.

26. Larman. Applying UML and Patterns, Second Edition. — Prentice Hall, 2001. (Ларман К.

Применение UML и шаблонов проектирования, 2-е изд. — К.: Диалектика, 2002.)

Сегодня это моя любимая книга по введению в объектно-ориентированное

проектирование.

530 Список основных источников информации

27. Lea. Concurrent Programming in Java, Second Edition. — Addison-Wesley, 2000.

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

гопоточных приложений.

28. Marinescu. EJB Design Patterns. — New York: John Wiley, 2002.

Сравнительно новая книга по типовым решениям для платформы Enterprise

Java Beans.

29. Martin and Odell. Object Oriented Methods: A Foundation (UML Edition). — Prentice

Hall, 1998.

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

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

30. Nilsson. .NET Enterprise Design with Visual Basic .NET and SQL Server 2000. —

Sams, 2002.

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

31. Vlissides, Coplien, and Kerth (eds.). Pattern Languages of Program Design 2. — Addison-

Wesley, 1996.

Сборник статей, посвященных типовым решениям.

32. Martin, Buschmann, and Riehle (eds.). Pattern Languages of Program Design 3. — Ad

dison-Wesley, 1998.

Сборник статей, посвященных типовым решениям.

33. Buschmann et al. Pattern-Oriented Software Architecture. — Wiley, 2000.

Лучшая книга по типовым решениям более общего характера.

34. Riehle, Seberski, Baumer, Megert, and Zullighoven. Serializer. — In: Pattern Languages

of Program Design 3 / Martin, Buschmann, and Riehle (eds.). —Addison-Wesley, 1998.

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

35. Schmidt, Stal, Rohnert, and Buschmann. Pattern-Oriented Software Architecture, Volume 2. —

New York: John Wiley, 2000.

Типовые решения для моделирования распределенных систем и систем с

параллельной обработкой заданий. Данная книга предназначена скорее для

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

небольшие знания на эту тему все же не помешают.

36. Snodgrass. Developing Time-Oriented Database Applications in SQL. — Morgan-

Kaufmann, 1999.

Рассматривается, как отслеживать историю данных в реляционной СУБД.

37. http://jakaria.apache.org/struts/

Описание набирающей популярность инфраструктуры Jakarta для плат-

формы Java, предназначенной для представления данных в Web.

Список основных источников информации 531

38. Waldo, Wyant, Wollrath, and Kendall. A Note on Distributed Computing. — SMLI TR-

94-29. — Sun Microsystems, 1994. http://research.sun.com/technical-reports/1994/

smli-tr-94-29.pdf.

Классическая статья на тему угрожающей бессмысленности выражения

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

39. http://c2.com/cgi/wiki

Оригинальная система общения Wild Wiki Web, разработанная Вэрдом

Каннинхэмом (Ward Cunningham). Достаточно сумбурный, тем не менее

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

мыми сумасшедшими идеями.

40. Woolf. Null Object.— In: Pattern Languages of Program Design3/Martin, Busch-

mann, and Riehle (eds.). — Addison-Wesley, 1998.

Описание типового решения null-объект (Null Object).

41. http://www.joeyoder. com/Research/objectmappings

Хороший источник по объектно-реляционным типовым решениям.

Предметный указатель

.NET, 125

ACID, 96

ADO.NET, 172

EJB2.0, 124

Enterprise Application Integration (EAI), 485

Enterprise Java Beans, 124

Globally Unique Identifier (GUID), 241

J2EE, 124

Web-службы, 126; 414

Автономный параллелизм, 87; 100; 87; 100

Активная запись (Active Record), 182

назначение, 184

пример: простой класс Person (Java), 184

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

Базы данных

отображение на объектную модель, 59

архитектурные решения, 59 взаимное

отображение объектов

и реляционных структур, 67

другие проблемы, 78

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

реализация отображения, 73

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

считывание данных, 66

функциональные проблемы, 64

Бизнес-логика, 46 Бизнес-

транзакция, 99 Блокировка

оптимистическая, 92

пессимистическая, 92

Блокировка с низкой степенью детализации

(Coarse-Grained Lock), 457 назначение, 460

пример: общая оптимистическая автономная

блокировка (Java), 460 пример: общая

пессимистическая автономная

блокировка (Java), 466 пример:

оптимистическая автономная

блокировка корневого элемента (Java), 467

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

Взаимоблокировка, 94 Виртуальный

прокси-объект, 221 Внедренное

значение

(Embedded Value), 288

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

назначение, 289

пример:простой объект-значение (Java), 290

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

Волнообразная загрузка, 222

Двухэтапное представление

(Two Step View), 383

назначение, 385

пример: двухэтапное применение XSLT

(XSLT), 390

пример:страницы JSP и пользовательские

дескрипторы (Java), 393

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

Деньги (Money), 502

назначение, 506

Предметный указатель 533

пример: класс Money (Java), 506

принцип действия, 503 Диспетчер

значения, 222 Длинная транзакция,

96 Дополнительный модуль (Plugin),

514

назначение, 515

пример: генератор идентификаторов

(Java), 516

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

Достоверность, 89

Единица работы (Unit of Work), 205

назначение, 211

пример: регистрация посредством

изменяемого объекта (Java), 212

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

Живучесть системы, 8

Загрузка по требованию (Lazy Load), 220

назначение, 223 пример: виртуальный

прокси-объект

(Java), 224 пример: инициализация

по требованию

(Java), 224 пример: использование

диспетчера значения

(Java), 226 пример: использование

фиктивных объектов

(С#), 227

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

Запрос, 89

Изолированность данных, 91

Изолированные потоки, 90

Инициализация по требованию, 221

Интерфейс удаленного доступа

(Remote Facade), 405

назначение, 410

пример: Web-служба (С#), 414

пример: использование компонента сеанса

Java в качестве интерфейса удаленного

доступа (Java), 410

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

Интерфейсы

локального вызова, 112

удаленного вызова, 112

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

архитектурные типовые решения источников

данных

активная запись (Active Record), 182

преобразователь данных (Data Mapper), 187

шлюз записи данных (Row

Data Gateway), 175

шлюз таблицы данных (Table Data

Gateway), 167

для модели предметной области, 122

для модуля таблицы, 122 для

сценария транзакции, 121 логика, 46

Катализаторы сложности, 50

Ключ

простой,238

составной,238

Коллекция объектов (Identity Map), 216

назначение, 219 пример: методы для работы с

коллекцией

объектов (Java) ,219

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

Контекст выполнения, 89

Контроллер запросов (Front

Controller), 362

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

назначение, 364

пример: простое отображение (Java), 365

принцип действия, 362 Контроллер

приложения (Application Controller), 397

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

назначение, 400 пример: модель состояний

контроллера

приложения (Java), 400 принцип действия,

398 Контроллер страниц (Page Controller),

350 назначение, 352 пример: использование

страницы JSP

в качестве обработчика запросов (Java), 355

пример: обработка запросов страницей сервера

с применением механизма разделения кода и

представления (Ot), 358

пример: простое отображение с помощью

контроллера-сервлета и представления JSP

(Java), 352 принцип действия, 351

Логика домена, 46

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

организация, 51