architektura systemów zarządzania przedsiębiorstwem. wzorce projektowe

Wydawnictwo Helion

ul. Chopina 6

44-100 Gliwice

tel. (32)230-98-63

e-mail: [email protected]

PRZYK£ADOWY ROZDZIA£PRZYK£ADOWY ROZDZIA£

IDZ DOIDZ DO

ZAMÓW DRUKOWANY KATALOGZAMÓW DRUKOWANY KATALOG

KATALOG KSI¥¯EKKATALOG KSI¥¯EK

TWÓJ KOSZYKTWÓJ KOSZYK

CENNIK I INFORMACJECENNIK I INFORMACJE

ZAMÓW INFORMACJEO NOWO�CIACH

ZAMÓW INFORMACJEO NOWO�CIACH

ZAMÓW CENNIKZAMÓW CENNIK

CZYTELNIACZYTELNIA

FRAGMENTY KSI¥¯EK ONLINEFRAGMENTY KSI¥¯EK ONLINE

SPIS TRE�CISPIS TRE�CI

DODAJ DO KOSZYKADODAJ DO KOSZYKA

KATALOG ONLINEKATALOG ONLINE

Architektura systemówzarz¹dzania przedsiêbiorstwem.Wzorce projektoweAutor: Martin Fowler

T³umaczenie: Pawe³ Koronkiewicz (wstêp, rozdz. 1 – 12),

Piotr Rajca (rozdz. 13 – 18, dod. A)

ISBN: 83-7361-715-9

Tytu³ orygina³u: Patterns of Enterprise Application Architecture

Format: B5, stron: 496

Wykorzystaj wzorce projektowe w pracy nad oprogramowaniem

• Zaprojektuj aplikacje o architekturze trójwarstwowej

• Dobierz odpowiedni¹ technologiê

• Stwórz modu³y aplikacji

Systemy informatyczne s³u¿¹ce do zarz¹dzania przedsiêbiorstwem to zwykle ogromne

aplikacje. Operuj¹ na milionach rekordów, przesy³aj¹ gigabajty danych i s¹ obs³ugiwane

przez dziesi¹tki u¿ytkowników. Sprawne dzia³anie takiej aplikacji jest niezwykle istotne

dla funkcjonowania przedsiêbiorstwa, dlatego musi ona byæ stabilna, a przed

wdro¿eniem -- gruntownie przetestowana. Przy tworzeniu aplikacji tego typu

wykorzystuje siê opracowane ju¿ rozwi¹zania, zwane wzorcami projektowymi.

Wzorce projektowe to modele poszczególnych komponentów aplikacji — nale¿y

jedynie zaimplementowaæ je w wybranym jêzyku programowania.

Ksi¹¿ka „Architektura systemów zarz¹dzania przedsiêbiorstwem. Wzorce projektowe”

to przegl¹d wzorców wykorzystywanych przy projektowaniu aplikacji korporacyjnych.

Opisuje zasady podzia³u aplikacji na warstwy i zasady wspó³pracy pomiêdzy warstwami;

przedstawia tak¿e modele komponentów wchodz¹cych w sk³ad ka¿dej z nich.

• Warstwy w aplikacjach biznesowych

• Wzorce logiki aplikacji

• Wzorce architektury �ród³a danych

• Wzorce mapowania obiektowo-relacyjnego

• Wzorce prezentacji

• Wzorce dystrybucji

• Wzorce stanu sesji

• Wzorce podstawowe

Korzystaj¹c z zawartych w ksi¹¿ce wzorców,stworzysz stabilne i wydajne aplikacje korporacyjne.

http://helion.pl/view/2547w



http://helion.pl/add/2547w/szabko




mailto:[email protected]

http://helion.pl/view/2547w/szabko.htm

http://www.amazon.com/exec/obidos/ASIN/0321127420/eboinf-20

Spis treści

Przedmowa.............................................................................................................13

Wstęp .....................................................................................................................19

Architektura .....................................................................................................................................................19Aplikacje korporacyjne ....................................................................................................................................20Rodzaje aplikacji dla przedsiębiorstw..............................................................................................................22Wydajność .......................................................................................................................................................23Wzorce .............................................................................................................................................................25

Struktura opisu wzorców ...........................................................................................................................27Ograniczenia wzorców projektowych........................................................................................................28

Część I Wprowadzenie 29

1.Warstwy aplikacji ..................................................................................................31

Podział warstwowy w aplikacjach dla przedsiębiorstw....................................................................................32Trzy główne warstwy.......................................................................................................................................33Układ warstw ...................................................................................................................................................35

2.Porządkowanie logiki dziedziny ............................................................................37

Wybór wzorca..................................................................................................................................................40Warstwa usług..................................................................................................................................................42

3.Mapowanie do relacyjnych baz danych.................................................................43

Wzorce architektury.........................................................................................................................................43Problem zachowań ...........................................................................................................................................47Odczyt danych .................................................................................................................................................48

6 SPIS TREŚCI

Wzorce mapowania struktury...........................................................................................................................49Mapowanie relacji .....................................................................................................................................49Dziedziczenie.............................................................................................................................................52

Proces budowy mapowania..............................................................................................................................54Podwójne mapowanie ................................................................................................................................55

Metadane..........................................................................................................................................................55Połączenie z bazą danych.................................................................................................................................56Inne problemy mapowania...............................................................................................................................58Warto przeczytać .............................................................................................................................................58

4.Prezentacja w sieci WWW ....................................................................................59

Wzorce widoku ................................................................................................................................................62Wzorce kontrolera danych wejściowych..........................................................................................................64Warto przeczytać .............................................................................................................................................64

5.Przetwarzanie współbieżne....................................................................................65

Problemy przetwarzania współbieżnego ..........................................................................................................66Konteksty przetwarzania..................................................................................................................................67Izolacja i niezmienność....................................................................................................................................68Optymistyczne i pesymistyczne sterowanie współbieżnością..........................................................................68

Zapobieganie niespójnym odczytom..........................................................................................................69Zakleszczenia.............................................................................................................................................70

Transakcje........................................................................................................................................................71ACID .........................................................................................................................................................72Zasoby transakcyjne ..................................................................................................................................72Zwiększanie żywotności przez ograniczanie izolacji.................................................................................73Transakcje biznesowe i systemowe ...........................................................................................................74

Wzorce sterowania współbieżnością w trybie offline ......................................................................................76Serwery aplikacji .............................................................................................................................................77Warto przeczytać .............................................................................................................................................78

6.Stan sesji ................................................................................................................79

Zalety sesji bezstanowej...................................................................................................................................79Stan sesji ..........................................................................................................................................................80

Metody przechowywania danych stanu sesji .............................................................................................81

7.Obiekty rozproszone ..............................................................................................85

Zwodnicze obiekty rozproszone ......................................................................................................................85Interfejsy lokalne i interfejsy zdalne ................................................................................................................86Kiedy stosować architekturę rozproszoną........................................................................................................87Granice dystrybucji ..........................................................................................................................................88Interfejsy dystrybucji .......................................................................................................................................89

SPIS TREŚCI 7

8.Podsumowanie .......................................................................................................91

Warstwa dziedziny, czyli początek ..................................................................................................................92Warstwa źródła danych, czyli krok drugi.........................................................................................................93

Źródło danych dla schematu Transaction Script (110) ..............................................................................93Źródło danych dla schematu Table Module (125) .....................................................................................93Źródło danych dla schematu Domain Model (116)....................................................................................94

Warstwa prezentacji.........................................................................................................................................94Wzorce a technologia.......................................................................................................................................95

Java i J2EE.................................................................................................................................................95.NET ..........................................................................................................................................................96Procedury przechowywane ........................................................................................................................97Usługi WWW ............................................................................................................................................97

Inne systemy warstw aplikacji .........................................................................................................................98

Część II Wzorce 101

9.Wzorce logiki dziedziny ......................................................................................103

Transaction Script (Skrypt transakcji)............................................................................................................103Na czym polega .......................................................................................................................................103Kiedy używamy .......................................................................................................................................105Problem obliczania przychodu.................................................................................................................105

Domain Model (Model dziedziny).................................................................................................................109Na czym polega .......................................................................................................................................109Kiedy używamy .......................................................................................................................................111Warto przeczytać .....................................................................................................................................112Przykład: uznanie przychodu (Java) ........................................................................................................112

Table Module (Moduł tabeli) .........................................................................................................................117Na czym polega .......................................................................................................................................118Kiedy używamy .......................................................................................................................................120Przykład: uznanie przychodu (C#)...........................................................................................................120

Service Layer (Warstwa usług) ......................................................................................................................124Na czym polega .......................................................................................................................................125Kiedy używamy .......................................................................................................................................127Warto przeczytać .....................................................................................................................................127Przykład: uznanie przychodu (Java) ........................................................................................................127

10.Wzorce architektury źródła danych .....................................................................133

Table Data Gateway (Brama danych tabeli) ..................................................................................................133Na czym polega........................................................................................................................................133Kiedy używamy .......................................................................................................................................134Warto przeczytać .....................................................................................................................................135Przykład: brama tabeli osób (C#) ............................................................................................................135Przykład: brama oparta na zbiorach danych ADO.NET (C#) ..................................................................137

8 SPIS TREŚCI

Row Data Gateway (Brama danych wiersza).................................................................................................140Na czym polega .......................................................................................................................................140Kiedy używamy .......................................................................................................................................142Przykład: brama rekordu osoby (Java).....................................................................................................142Przykład: uchwyt danych dla obiektu dziedziny (Java) ...........................................................................146

Active Record (Rekord aktywny) ..................................................................................................................147Na czym polega .......................................................................................................................................147Kiedy używamy .......................................................................................................................................148Przykład: prosta tabela osób (Java)..........................................................................................................148

Data Mapper (Odwzorowanie danych) ..........................................................................................................152Na czym polega .......................................................................................................................................152Kiedy używamy .......................................................................................................................................156Przykład: proste odwzorowanie obiektowo-relacyjne (Java) ...................................................................157Przykład: wyłączanie metod wyszukujących (Java) ................................................................................162Przykład: tworzenie obiektu pustego (Java).............................................................................................165

11.Wzorce zachowań dla mapowania obiektowo-relacyjnego.................................169

Unit of Work (Jednostka pracy) .....................................................................................................................169Na czym polega .......................................................................................................................................170Kiedy używamy .......................................................................................................................................173Przykład: rejestracja przez obiekt (Java)..................................................................................................174

Identity Map (Mapa tożsamości)....................................................................................................................178Na czym polega .......................................................................................................................................178Kiedy używamy .......................................................................................................................................180Przykład: metody mapy tożsamości (Java) ..............................................................................................181

Lazy Load (Opóźnione ładowanie) ................................................................................................................182Na czym polega .......................................................................................................................................182Kiedy używamy .......................................................................................................................................184Przykład: opóźniona inicjalizacja (Java)..................................................................................................185Przykład: wirtualny pośrednik (Java).......................................................................................................185Przykład: uchwyt wartości (Java) ............................................................................................................187Przykład: widmo (C#)..............................................................................................................................188

12.Wzorce struktury dla mapowania obiektowo-relacyjnego ..................................197

Identity Field (Pole tożsamości).....................................................................................................................197Na czym polega .......................................................................................................................................197Kiedy używamy .......................................................................................................................................201Warto przeczytać .....................................................................................................................................201Przykład: liczba całkowita jako klucz (C#)..............................................................................................201Przykład: tabela kluczy (Java) .................................................................................................................203Przykład: klucz złożony (Java) ................................................................................................................205

Foreign Key Mapping (Odwzorowanie do klucza obcego)............................................................................216Na czym polega .......................................................................................................................................216Kiedy używamy .......................................................................................................................................218Przykład: odwołanie jednowartościowe (Java) ........................................................................................219Przykład: wyszukiwanie w wielu tabelach (Java) ....................................................................................222Przykład: kolekcja odwołań (C#).............................................................................................................223

SPIS TREŚCI 9

Association Table Mapping (Odwzorowanie do tabeli asocjacji) ..................................................................226Na czym polega .......................................................................................................................................226Kiedy używamy .......................................................................................................................................227Przykład: pracownicy i umiejętności (C#)...............................................................................................227Przykład: odwzorowanie z kodem SQL (Java) ........................................................................................230Przykład: jedno zapytanie do obsługi wielu pracowników (Java)............................................................234

Dependent Mapping (Odwzorowanie składowych) .......................................................................................239Na czym polega .......................................................................................................................................239Kiedy używamy .......................................................................................................................................240Przykład: albumy i ścieżki (Java) ............................................................................................................241

Embedded Value (Wartość osadzona) ...........................................................................................................244Na czym polega .......................................................................................................................................244Kiedy używamy .......................................................................................................................................244Warto przeczytać .....................................................................................................................................245Przykład: prosty obiekt wartości (Java) ...................................................................................................245

Serialized LOB (Duży obiekt serializowany).................................................................................................247Na czym polega .......................................................................................................................................247Kiedy używamy .......................................................................................................................................248Przykład: serializowanie hierarchii działów firmy do postaci XML (Java) .............................................249

Single Table Inheritance (Odwzorowanie dziedziczenia do pojedynczej tabeli) ...........................................252Na czym polega .......................................................................................................................................252Kiedy używamy .......................................................................................................................................253Przykład: tabela zawodników (C#) ..........................................................................................................253

Class Table Inheritance (Odwzorowanie dziedziczenia do tabel klas)...........................................................259Na czym polega .......................................................................................................................................259Kiedy używamy .......................................................................................................................................260Warto przeczytać .....................................................................................................................................260Przykład: zawodnicy (C#)........................................................................................................................260

Concrete Table Inheritance (Odwzorowanie dziedziczenia do tabel konkretnych)........................................266Na czym polega .......................................................................................................................................266Kiedy używamy .......................................................................................................................................268Przykład: zawodnicy (C#)........................................................................................................................268

Inheritance Mappers (Klasy odwzorowania dziedziczenia) ...........................................................................274Na czym polega .......................................................................................................................................275Kiedy używamy .......................................................................................................................................276

13.Wzorce odwzorowań obiektów i relacyjnych metadanych .................................277

Metadata Mapping (Odwzorowanie metadanych) .........................................................................................277Na czym polega .......................................................................................................................................277Kiedy używamy .......................................................................................................................................279Przykład: użycie metadanych i odzwierciedlania (Java)..........................................................................280

Query Object (Obiekt zapytania) ...................................................................................................................287Na czym polega .......................................................................................................................................287Kiedy używamy .......................................................................................................................................288Warto przeczytać .....................................................................................................................................289Przykład: prosty wzorzec Obiekt zapytania (Java) ..................................................................................289

Repository (Magazyn)....................................................................................................................................293Na czym polega .......................................................................................................................................294Kiedy używamy .......................................................................................................................................295Warto przeczytać .....................................................................................................................................296Przykład: odnajdywanie osób utrzymywanych przez podaną osobę (Java) .............................................296Przykład: zamiana strategii wzorca Repository (Java).............................................................................297

10 SPIS TREŚCI

14.Wzorce prezentacji internetowych.......................................................................299

Model View Controller (Model kontrolera widoku) ......................................................................................299Na czym polega .......................................................................................................................................299Kiedy używamy .......................................................................................................................................301

Page Controller (Kontroler strony) ................................................................................................................302Na czym polega .......................................................................................................................................302Kiedy używamy .......................................................................................................................................303Przykład: prosta prezentacja z serwletem pełniącym funkcję kontrolera

oraz stroną JSP pełniącą rolę widoku (Java) ........................................................................................304Przykład: zastosowanie strony JSP do obsługi żądania (Java).................................................................306Przykład: mechanizm obsługi stron wykorzystujący kod schowany (C#) ............................................309

Front Controller (Kontroler fasady) ...............................................................................................................313Na czym polega .......................................................................................................................................313Kiedy używamy .......................................................................................................................................315Warto przeczytać .....................................................................................................................................315Przykład: prosta prezentacja (Java)..........................................................................................................315

Template View (Szablon widoku)..................................................................................................................318Na czym polega .......................................................................................................................................318Kiedy używamy .......................................................................................................................................322Przykład: wykorzystanie JSP jako widoku wraz z osobnym kontrolerem (Java) .....................................322Przykład: strona ASP.NET (C#) ..............................................................................................................325

Transform View (Widok przekształcający)....................................................................................................328Na czym polega .......................................................................................................................................328Kiedy używamy .......................................................................................................................................329Przykład: proste przekształcenie (Java) ...................................................................................................330

Two Step View (Widok dwuetapowy)...........................................................................................................332Na czym polega .......................................................................................................................................332Kiedy używamy .......................................................................................................................................333Przykład: dwuetapowe przekształcenie XSLT (XSLT) ...........................................................................338Przykład: JSP i znaczniki niestandardowe (Java) ....................................................................................340

Application Controller (Kontroler aplikacji)..................................................................................................345Na czym polega .......................................................................................................................................345Kiedy używamy .......................................................................................................................................347Warto przeczytać .....................................................................................................................................347Przykład: kontroler aplikacji obsługujący model stanu (Java) .................................................................347

15.Wzorce dystrybucji ..............................................................................................353

Remote Facade (Zdalna fasada) .....................................................................................................................353Na czym polega .......................................................................................................................................354Kiedy używamy .......................................................................................................................................357Przykład: zastosowanie komponentu session bean i zdalnej fasady (Java)..............................................357Przykład: usługa WWW (C#) ..................................................................................................................360

Data Transfer Object (Obiekt transferu danych) ............................................................................................366Na czym polega .......................................................................................................................................366Kiedy używamy .......................................................................................................................................370Warto przeczytać .....................................................................................................................................371Przykład: przekazywanie informacji o albumach (Java)..........................................................................371Przykład: serializacja danych do postaci XML (Java) .............................................................................375

SPIS TREŚCI 11

16.Wzorce współbieżności autonomicznej...............................................................379

Optimistic Offline Lock (Optymistyczna blokada autonomiczna) .................................................................379Na czym polega .......................................................................................................................................380Kiedy używamy .......................................................................................................................................383Przykład: warstwa dziedziny i wzorzec Data Mappers (165) (Java).............................................................384

Pessimistic Offline Lock (Pesymistyczna blokada autonomiczna) ................................................................389Na czym polega .......................................................................................................................................390Kiedy używamy .......................................................................................................................................393Przykład: prosty menedżer blokad (Java) ................................................................................................394

Coarse-Grained Lock (Blokada gruboziarnista).............................................................................................400Na czym polega .......................................................................................................................................400Kiedy używamy .......................................................................................................................................402Przykład: wspólna blokada Optimistic Offline Lock (416) (Java)...........................................................403Przykład: wspólna blokada Pessimistic Offline Lock (426) (Java)..........................................................408Przykład: blokowanie korzenia przy użyciu blokady Pessimistic Offline Lock (416) (Java) ...................409

Implicit Lock (Blokada domyślna) ................................................................................................................410Na czym polega .......................................................................................................................................411Kiedy używamy .......................................................................................................................................412Przykład: niejawna blokada Pessimistic Offline Lock (426) (Java).........................................................412

17.Wzorce stanu sesji................................................................................................415

Client Session State (Stan sesji klienta) .........................................................................................................415Na czym polega .......................................................................................................................................415Kiedy używamy .......................................................................................................................................416

Server Session State (Stan sesji serwera) .......................................................................................................418Na czym polega .......................................................................................................................................418Kiedy używamy .......................................................................................................................................420

Database Session State (Stan sesji bazy danych) ...........................................................................................421Na czym polega .......................................................................................................................................421Kiedy używamy .......................................................................................................................................423

18.Wzorce podstawowe ............................................................................................425

Gateway (Brama) ...........................................................................................................................................425Na czym polega .......................................................................................................................................426Kiedy używamy .......................................................................................................................................426Przykład: brama pośrednicząca w korzystaniu z usługi rozsyłania komunikatów (Java).........................427

Mapper (Odwzorowanie) ...............................................................................................................................432Na czym polega .......................................................................................................................................432Kiedy używamy........................................................................................................................................433

Layer Supertype (Typ bazowy warstwy) .......................................................................................................434Na czym polega .......................................................................................................................................434Kiedy używamy .......................................................................................................................................434Przykład: obiekt domeny (Java)...............................................................................................................434

Separated Interface (Interfejs oddzielony) .....................................................................................................435Na czym polega .......................................................................................................................................435Kiedy używamy .......................................................................................................................................437

12 SPIS TREŚCI

Registry (Rejestr) ...........................................................................................................................................438Na czym polega .......................................................................................................................................438Kiedy używamy .......................................................................................................................................440Przykład: rejestr bazujący na wzorcu Singleton (Java)............................................................................440Przykład: rejestr nadający się do zastosowania w środowiskach wielowątkowych (Java).......................442

Value Object (Obiekt wartości)......................................................................................................................444Na czym polega .......................................................................................................................................444Kiedy używamy .......................................................................................................................................445

Money (Pieniądze) .........................................................................................................................................446Na czym polega .......................................................................................................................................446Kiedy używamy .......................................................................................................................................448Przykład: klasa Money (Java) ..................................................................................................................449

Special Case (Przypadek szczególny) ............................................................................................................453Na czym polega .......................................................................................................................................453Kiedy używamy .......................................................................................................................................454Warto przeczytać .....................................................................................................................................454Przykład: prosta implementacja pustego obiektu (C#).............................................................................454

Plugin.............................................................................................................................................................456Na czym polega .......................................................................................................................................456Kiedy używamy .......................................................................................................................................457Przykład: generator identyfikatorów (Java) .............................................................................................457

Service Stub (Usługa zastępcza) ....................................................................................................................461Na czym polega .......................................................................................................................................461Kiedy używamy .......................................................................................................................................462Przykład: usługa podatkowa (Java)..........................................................................................................462

Record set (Zbiór rekordów)..........................................................................................................................465Na czym polega .......................................................................................................................................465Kiedy używamy .......................................................................................................................................467

Dodatki 469

Bibliografia ..........................................................................................................471

Skorowidz ............................................................................................................477

9Wzorce logiki dziedziny

Transaction Script (Skrypt transakcji)

Porządkuje logikę dziedziny w procedury, gdzie każda procedura

obsługuje pojedyncze żądanie warstwy prezentacji.

Pracę większości aplikacji biznesowych można rozpatrywać jako przetwarzanie sekwencji trans-akcji. Transakcja może polegać na przeglądaniu danych w pewien określony sposób lub wprowa-dzaniu w nich zmian. Każda interakcja między systemem klienckim a systemem serwera obejmujepewną część logiki aplikacji. W pewnych przypadkach interakcja może być tak prosta jak wy-świetlanie przechowywanych w bazie danych. W innym może wymagać wielu operacji sprawdza-nia poprawności i obliczeń.

Wzorzec Transaction Script porządkuje logikę takiej interakcji jako, ogólnie rzecz biorąc,pojedynczą procedurę, która wywołuje bazę danych bezpośrednio lub za pośrednictwem prostegokodu osłaniającego. Każda transakcja ma własny skrypt. Dodatkową optymalizacją może być łą-czenie wspólnych fragmentów kodu w podprocedury.

Na czym polega

Gdy stosujemy wzorzec Transaction Script, logika domeny porządkowana jest zasadniczo wedługwykonywanych w systemie transakcji. Gdy celem transakcji jest wprowadzenie rezerwacji pokojuhotelowego, kod pojedynczej procedury Zarezerwuj Pokój obejmuje sprawdzenie dostępności po-koi, określenie wysokości opłaty i zaktualizowanie bazy danych.

104 9. WZORCE LOGIKI DZIEDZINY

W prostych przypadkach sposób porządkowania skryptów transakcji jest naturalny. Oczywi-ście, podobnie jak w każdym programie, powinniśmy wprowadzić przejrzystą strukturę modułów.O ile transakcja nie jest szczególnie skomplikowana, jest to bardzo proste. Jedną z zalet skryptówtransakcji jest to, że nie ma dla nich znaczenia, jakie operacje wykonują inne transakcje. Zadaniemimplementowanego kodu jest przyjęcie danych wejściowych, odczytanie danych z bazy, prze-kształcenie ich, a następnie zapisanie wyników w bazie.

O tym, gdzie umieścimy skrypt transakcji, decyduje przyjęty system warstw aplikacji. Loka-lizacją taką może być strona serwera, skrypt CGI lub rozproszony obiekt sesji. Dobrze jest roz-dzielać skrypty tak dalece, jak to możliwe. Absolutnym minimum są osobne procedury. Jeszczelepsze są klasy, oddzielone również od kodu prezentacji i źródła danych. Dodatkowo, w skryptachtransakcji nie wprowadzamy żadnych wywołań logiki prezentacji. Ułatwia to ich modyfikowaniei testowanie.

Skrypty transakcji można porządkować w klasy dwoma sposobami. Najbardziej typowympodejściem jest łączenie w jednej klasie grupy skryptów. Każda klasa odpowiada wtedy pewnemuzakresowi tematycznemu. Układ taki jest przejrzysty i sprawdza się w praktyce. Inną możliwościąjest umieszczanie każdego skryptu w osobnej klasie (patrz rysunek 9.1). Odpowiada to wzorcowiCommand Gang of Four. Definiujemy wtedy również supertyp takich poleceń, który określa pew-ną metodę uruchamiania skryptów. Pozwala to operować skryptami jako obiektami. Trzeba przy-znać, że potrzeba taka pojawia się stosunkowo rzadko, ze względu na prostotę systemów, gdziestosuje się wzorzec Transaction Script. Oczywiście, wiele języków pozwala zapomnieć o klasachi definiować funkcje globalne. Nie można jednak zapominać, że tworzenie egzemplarzy obiektówpomaga izolować dane różnych wątków przetwarzania.

RYSUNEK 9.1. Skrypty transakcji jako polecenia

Termin „skrypt transakcji” jest o tyle uzasadniony, że w większości przypadków każdy z nichodpowiada pojedynczej transakcji bazy danych. Nie jest to reguła obowiązująca we wszystkichprzypadkach, ale jest stosunkowo dobrym przybliżeniem.

TRANSACTION SCRIPT (SKRYPT TRANSAKCJI) 105

Kiedy używamy

Wielką zaletą skryptów transakcji jest ich prostota. Porządkowanie logiki przy ich użyciu jest bar-dzo naturalne, gdy cała aplikacja zawiera niewiele kodu. Nie wprowadzamy dodatkowych pozio-mów złożoności ani elementów obniżających wydajność.

Gdy logika biznesowa staje się bardziej skomplikowana, utrzymanie porządku w skryptachtransakcji staje się coraz bardziej skomplikowane. Podstawowym problemem są powtórzenia ko-du. Ponieważ każdy skrypt ma obsłużyć dokładnie jedną transakcję, powtórne wprowadzanie ta-kich samych lub podobnych fragmentów jest nieuniknione.

Uważny programista uniknie większości takich problemów, jednak większe aplikacje wyma-gają zbudowania modelu dziedziny. Wzorzec Domain Model (109) zapewnia znacznie więcej opcjistrukturalizowania kodu, większą przejrzystość i ograniczenie problemu powtórzeń.

Trudno określić poziom złożoności, na którym skrypty transakcji nie mogą być zastosowane.Będzie to jeszcze trudniejsze, jeżeli przyzwyczailiśmy się do jednego z wzorców. Można oczywiścieprzekształcić skrypty transakcji w model dziedziny, ale nie jest to zmiana prosta, więc dobrze by-łoby zastanowić się nad właściwym podejściem już na samym początku.

Bez względu na to, jak bardzo lubimy podejście obiektowe, nie powinniśmy skreślać wzorcaTransaction Script. Jest wiele prostych problemów i stosowanie dla nich prostych rozwiązań po-zwala szybciej zakończyć pracę.

Problem obliczania przychodu

Do zilustrowania tego i dalszych wzorców logiki dziedziny będę używał tego samego problemu.Poniżej przedstawiam jego opis, którego już przy kolejnych wzorcach nie będę niepotrzebniepowtarzał.

Obliczanie uznania przychodu (ang. revenue recognition) to dość typowe dla systemów biz-nesowych zagadnienie. Podstawowym problemem jest to, kiedy można zaksięgować otrzymanyprzychód (ang. revenue). Gdy sprzedaję filiżankę kawy, sytuacja jest prosta: wydaję kawę, biorępieniądze i natychmiast wprowadzam odpowiednią kwotę do książki przychodów. Nie zawszejednak jest tak łatwo. Wyobraźmy sobie, że dostaję zaliczkę na ten rok. Nawet jeżeli jest to nie-wielka kwota, jej natychmiastowe wprowadzenie do książki może nie być możliwe, ponieważusługa będzie wykonana dopiero na przestrzeni tego roku. Jedną z możliwości może być wprowa-dzanie jednej dwunastej tej kwoty w każdym kolejnym miesiącu, na wypadek, gdyby umowa zo-stała nagle rozwiązana.

Jest wiele różnych i często zmiennych reguł obliczania przychodu na potrzeby urzędu skar-bowego. Część ustala ustawa, inne wynikają ze standardów księgowości, jeszcze inne — z we-wnętrznych zasad firmy. Śledzenie przychodu może być bardzo złożonym zagadnieniem.

Nie będziemy się tutaj wgłębiać w szczegóły tego procesu. Wyobraźmy sobie jedynie fir-mę, która sprzedaje trzy rodzaje towarów: edytory tekstu, bazy danych i arkusze kalkulacyjne.Zgodnie z przyjętymi zasadami, całość przychodu z umowy sprzedaży (ang. contract) edytoratekstu może zostać zaksięgowana od razu. W przypadku arkusza kalkulacyjnego, jedną trzeciąprzychodu wprowadzamy od razu, jedną trzecią po sześćdziesięciu dniach i pozostałą jednątrzecią po dziewięćdziesięciu dniach. Gdy sprzedajemy bazę danych, jedną trzecią wprowadzamyod razu, jedną trzecią po trzydziestu dniach i jedną trzecią po sześćdziesięciu dniach. Oczywi-ście zasady te niewiele mają wspólnego z rzeczywistością i mają służyć jedynie zilustrowaniu oma-wianych zagadnień.


RYSUNEK 9.2. Uproszczony model obliczania przychodu. Każda umowa obejmuje wiele wartości

przychodu, powiązanych z określeniem, kiedy różne części przychodu trafiają do ksiąg

Przykład: uznanie przychodu (Java)

W niniejszym przykładzie stosujemy dwa skrypty transakcji: jeden do obliczania uznań przychodudla danej umowy i drugi do określenia, jaka kwota przychodu z danej umowy została uznana dookreślonego dnia. Baza danych ma trzy tabele: towarów (ang. products), umów (ang. contracts) i uznańprzychodu (ang. revenue recognitions).

�� !�� !�� !��"��#��$��%��&�'�&��!��"��#��

Pierwszy skrypt oblicza kwotę uznania na dany dzień. Można ją wyliczyć w dwóch krokach: w pierw-szym wybieramy wiersze tabeli uznań przychodu, w drugim sumujemy kwoty.

Projekty oparte na wzorcu Transaction Script korzystają często ze skryptów, które operująbezpośrednio na bazie danych, wykorzystując kod SQL. W tym przykładzie korzystamy z prostejbramy Table Data Gateway (133) jako osłony zapytań SQL. Ze względu na prostotę przykładu,użyjemy tylko jednej, wspólnej bramy, nie tworząc osobnych dla każdej tabeli. Definiujemy w jejobrębie odpowiednią metodę wyszukiwania, (��!��)�.

��*��+��,,,

�� -�� (��!��)��!��%(��(��+�� .��/��0��$�� 1��-,�� (��!�� 2��,��!�3��2��,��4��(,�� 5��2�� 1��,�/�� . ��2�� 2��6��(�� !�(��!�� 1��7 �� 7�8��7��)�#%�� !��7�8��7��9:��1�;��<��!��"��#��=1�;72��-2

TRANSACTION SCRIPT (SKRYPT TRANSAKCJI) 107

Drugi skrypt służy do podsumowania danych przekazanych przez bramę.

��!�� ,,,

�� -��%��!��"�� !��< �-��%(��(�0��%�� 1�%��,��>�2��0�� 1��-,(��!��)��< �-��(�2��+��,��/��0�� 1�� ,��%��,��,!��!��7�� 7��2��6�� 2��6�� .��/��0��+��+��/��2��6��6

W przypadku tak prostych obliczeń, procedura w języku Java mogłaby również zostać zastąpionawywołaniem SQL, które sumuje wartości przy użyciu funkcji agregującej.

Podobny podział stosujemy przy obliczaniu uznań przychodu dla wybranej umowy. Skryptwarstwy dziedziny realizuje logikę biznesową.

��!�� ,,,

�� -�� !��!��< �-��0��0�� 1��-,(��< �-��2��,��/��2��%�� 1�%��,��,!��!��7�� 7��2��%(��!��1��+�%(��,!��7�� !��7��2�� !��1��,!�� !�7��7�2��(��,�5 ��7 7��0��%��?@��1�� ,��A�2��-,��!��< �-��?>@��!��2��-,��!��< �-��?3@��!��,��B>��2��-,��!��< �-��?4@��!��,��C>��2��6��(��,�5 ��797��0��-,��!��< �-�� !��2��6��(��,�5 ��7�7��0��%��?@��1�� ,��A�2��-,��!��< �-��?>@��!��2��-,��!��< �-��?3@��!��,��A>��2��-,��!��< �-��?4@��!��,��B>��2��6��6�� .��/��0��+��+��/��2��6��6


Zwróćmy uwagę na użycie klasy Money (446) do alokacji. Zapobiega ona gubieniu pojedynczychgroszy (lub centów), o co łatwo przy dzieleniu kwot pieniężnych przez trzy.

Obsługa SQL jest zrealizowana w formie wzorca Table Data Gateway (133). Pierwsza proceduraznajduje umowę.

��*��+��,,,

�� -�� (��!��+�� .��/��0��$�� 1��-,�� (�� 2��,��!�3��2�� 1��,�/�� . ��2�� 2��6��(�� !�(�� 1��7 ��D�7�8��7��)�#%�� 7�8��7��9:��1�;��<��,�� 1�,��72

Druga procedura to osłona instrukcji �< ��.

��*��+��,,,

�� -��!��!��%�� %(��(��+�� .��/��0��$�� 1��-,�� !�� 2��,��!�3��2��,��!��4�� ,�� 2��,��A��(,�� 5��2��,�/�� E��2��6��(�� !��!�� 1��7�< ��<�#�� !��F��E� ��;��;��;�72

Gdy używamy języka Java, usługa obliczania uznań dochodu może mieć postać tradycyjnej klasylub obiektu bean sesji.

Czytelnik, który nie jest przyzwyczajony do modelowania dziedziny, uzna prawdopodobnieprzedstawioną tu implementację za znacznie prostszą niż przedstawiona w opisie wzorca Domain

Model (109). Niestety, nieco trudniej w zwięzły sposób przedstawić (lub wyobrazić sobie), co sta-nie się, gdy reguły biznesowe będą bardziej skomplikowane. Stosowane w praktyce reguły obli-czania uznań przychodu nie są proste, a różnice między nimi wyznacza nie tylko produkt, któregodotyczą, ale i data operacji („jeżeli umowa została podpisana przed 15 kwietnia, obowiązuje takaa taka reguła”). Gdy poziom złożoności jest duży, utrzymanie spójnej konstrukcji skryptów trans-akcji jest bardzo trudne, co doskonale uzasadnia przywiązanie miłośników podejścia obiektowegodo stosowania modeli dziedziny.

DOMAIN MODEL (MODEL DZIEDZINY) 109

Domain Model (model dziedziny)

Obiektowy model dziedziny, obejmujący wymagane zachowania i dane.

Logika biznesowa może osiągnąć bardzo duży poziom złożoności. Reguły i logika opisują wieleróżnych przypadków i wariantów zachowań, a właśnie rozwiązanie problemu złożoności byłogłówną przesłanką stworzenia koncepcji obiektów. Model dziedziny to sieć takich połączonych zesobą obiektów, gdzie każdy obiekt reprezentuje pewien znaczący element lub czynnik. Elementyte mogą być tak znaczne jak przedsiębiorstwo lub tak niewielkie jak pojedynczy wiersz formularzazamówienia.

Na czym polega

Wprowadzenie w aplikacji wzorca Domain Model (109) wymaga stworzenia dość rozbudowanejkoncepcyjnie warstwy obiektów, które modelują rozwiązywany problem. Należą do nich obiektyreprezentujące dane przedsiębiorstwa i obiekty odpowiadające regułom jego pracy. Dane i procesynajczęściej łączy się ze sobą, aby skupić czynności przetwarzania i informacje, którymi operują.

Obiektowy model dziedziny może przypominać model bazy danych, zawsze jednak dzielą jeistotne różnice. Model dziedziny łączy dane i procesy, ma wielowartościowe atrybuty, złożonąsieć asocjacji i wykorzystuje dziedziczenie.

Można wyróżnić dwa rodzaje modeli dziedziny. Prosty model przypomina projekt bazy da-nych i dominuje w nim układ „jeden obiekt modelu-jedna tabela bazy danych”. Rozbudowanymodel dziedziny znacznie odbiega od struktury bazy i wykorzystuje dziedziczenie, strategie i innewzorce Gang of Four, jak również złożone sieci niewielkich, połączonych ze sobą obiektów. Takie


podejście jest lepsze, gdy logika jest bardziej skomplikowana, trudniej jednak wówczas przepro-wadzić mapowanie do bazy. W prostym modelu można korzystać z aktywnych rekordów (Active

Record (147)), rozbudowany wymaga mechanizmu Data Mapper (152).Ponieważ funkcje biznesowe wymagają zawsze wielu późniejszych zmian, ważna jest możli-

wość łatwego modyfikowania, kompilowania i testowania warstwy, w której są implementowane.Musimy więc dbać o to, aby sprzężeń między modelem a innymi warstwami systemu było jaknajmniej. Łatwo zauważyć, że podstawą wielu wzorców układu warstwowego jest właśnie utrzy-manie jak najmniejszej zależności między warstwą dziedziny a innymi.

Rozwiązania obsługi modelu dziedziny mogą być różne. Najprostszym przypadkiem jestaplikacja dla jednego użytkownika, gdzie cały graf obiektów zostaje odczytany z pliku i załado-wany do pamięci. O ile sprawdza się to w przypadku aplikacji biurowych, nie jest raczej stosowa-ne w wielowarstwowych aplikacjach systemów informacyjnych z tej prostej przyczyny, że obiektówjest wtedy zbyt wiele. Pamięć jest zbyt mała, aby takie obciążenie było uzasadnione, a samo łado-wanie obiektów trwa zbyt długo. Urok obiektowych baz danych polega właśnie na tym, że zapewniająiluzję wykonywania takiej operacji, podczas gdy w rzeczywistości jedynie zarządzają przenoszeniemobiektów pomiędzy pamięcią a dyskiem.

Brak obiektowej bazy danych zmusza do samodzielnego projektowania podobnych rozwiązań.W typowym przypadku w każdej sesji ładowany jest graf obiektów, których ta sesja wymaga. Niesą to jednak nigdy wszystkie obiekty aplikacji i zazwyczaj nie wszystkie stosowane klasy. Przykła-dowo, gdy przeglądany jest zbiór umów, z dysku ładowane są tylko obiekty odpowiadające pro-duktom, do których te umowy się odwołują. Gdy przeprowadzane są obliczenia operujące umowamii uznaniami przychodu, obiekty reprezentujące produkty mogą nie być ładowane w ogóle. O tym,co zostanie załadowane do pamięci, decydują obiekty zarządzające mapowaniem do bazy danych.

Gdy pojawia się potrzeba utrzymania tego samego grafu obiektów pomiędzy kolejnymi wy-wołaniami serwera, niezbędne jest zachowanie danych stanu. To zagadnienie omawiamy w roz-dziale poświęconym stanowi sesji (strona 79).

Typowym problemem związanym z logiką dziedziny jest nadmierne „puchnięcie” obiektów.W trakcie projektowania ekranu do zarządzania zamówieniami możemy zauważyć, że niektórefunkcje zamówień służą wyłącznie do jego obsługi. Przypisanie tych funkcji zamówieniu możedoprowadzić do niepotrzebnej rozbudowy odpowiedniej klasy. Niepotrzebnej, ponieważ wielefunkcji wykorzystanych zostaje tylko w jednym przypadku użycia. Wielu programistów zwracawięc pilnie uwagę na to, czy pewne funkcje mają charakter ogólny (i mogą być implementowanew klasie Zamówienie), czy są specyficzne dla określonych operacji. W tym ostatnim przypadku po-winny być implementowane w pewnej klasie związanej z zastosowaniem obiektu. Może to oznaczaćskrypt transakcji lub warstwę prezentacji.

Problem oddzielania zachowań specyficznych dla zastosowań obiektu jest powiązany z zagad-nieniem duplikacji kodu. Funkcję oddzieloną od zamówienia trudniej znaleźć, łatwo więc — napewnym etapie projektu — o przeoczenie prowadzące do ponownej implementacji tego samegozachowania. Powtórzenia kodu z kolei prowadzą do szybkiego zwiększania jego złożoności i utratyspójności. Z moich doświadczeń wynika, że „puchnięcie” obiektów nie jest tak częstym zjawi-skiem, jak mogłoby się na pierwszy rzut oka wydawać. Choć nie można zaprzeczyć jego występo-waniu, łatwo je wykryć i wprowadzić niezbędne korekty. Zalecałbym więc raczej powstrzymaniesię od oddzielania funkcji od obiektów i implementowanie ich w tych klasach, gdzie w naturalnysposób pasują. „Odchudzanie” obiektów stosujemy dopiero wtedy, gdy faktycznie stwierdzimy, żejest konieczne.


Implementacja w języku Java

Implementowanie modelu dziedziny w J2EE wzbudza mnóstwo emocji. Wiele materiałów szkoleniowych

i podręczników zaleca stosowanie do tego celu obiektów entity bean. Podejście takie wiąże się jednak

z pewnymi poważnymi trudnościami. Być może zostaną one usunięte w przyszłych wersjach specyfika-

cji (w chwili pisania tej książki obowiązuje wersja 2.0).

Obiekty entity bean najlepiej sprawdzają się, gdy stosujemy mechanizm Container Managed Per-

sistance (CMP, kontenerowo zarządzane składowanie). Można wręcz stwierdzić, że w innych rozwią-

zaniach stosowanie obiektów entity bean nie ma uzasadnienia. CMP jest jednak dość ograniczoną formą

mapowania obiektowo-relacyjnego i nie pozwala stosować wielu wzorców potrzebnych w rozbudowa-

nych modelach dziedziny.

Obiekty entity bean nie powinny mieć charakteru wielobieżnego, co znaczy, że jeżeli obiekt entity

bean wywołuje inny obiekt, ten inny obiekt (ani żaden inny w łańcuchu dalszych wywołań) nie może

wywołać pierwszego obiektu entity bean. Jest to o tyle kłopotliwe, że rozbudowane modele dziedziny

często wykorzystują wielobieżność. Co gorsza, zachowania tego rodzaju są trudne do wykrycia. Prowa-

dzi to do popularnego zalecenia, aby obiekty entity bean nie wywoływały się wzajemnie. Pozwala to co

prawda uniknąć wielobieżności, ale znacznie ogranicza korzyści ze stosowania wzorca Domain Model.

Model dziedziny powinien opierać się na obiektach z interfejsami o dużej ziarnistości (podobna cecha

powinna charakteryzować samą strukturę obiektów). Jednak zdalne wywoływanie obiektów z interfej-

sami o dużej ziarnistości prowadzi do bardzo niskiej wydajności systemu. W konsekwencji, pomimo tego,

że obiekty entity bean mogą być dostosowane do wywołań zdalnych (we wcześniejszych wersjach specy-

fikacji była to wymagana cecha), w modelu dziedziny powinniśmy stosować wyłącznie interfejsy lokalne.

Aby korzystać z obiektów entity bean, niezbędny jest kontener i połączenie z bazą danych. Zwiększa

to czas kompilacji i czas niezbędny do wykonania testów, bo obiekty te muszą korzystać z bazy danych.

Również debugowanie obiektów entity bean nie należy do najprostszych.

Alternatywą jest stosowanie zwykłych obiektów języka Java, nawet jeżeli takie podejście może być

dla wielu osób zaskakujące — zadziwiające, jak wielu programistów jest utwierdzonych w przekonaniu,

że w kontenerze EJB nie mogą pracować zwykłe obiekty. Doszedłem kiedyś do wniosku, że zwykłe

obiekty Java idą w zapomnienie, bo nie mają ładnej nazwy. Dlatego właśnie, przygotowując się do pewnej

dyskusji w 2000 roku, razem z Rebeccą Parsons i Joshem Mackenzie wymyśliliśmy nazwę POJO (ang.

plain old Java objects, zwykłe obiekty języka Java). Model dziedziny oparty na obiektach POJO stosun-

kowo łatwo jest opracować, szybko się kompiluje, a można go uruchamiać i testować poza kontenerem EJB.

Jest on zasadniczo niezależny od EJB (co być może jest przyczyną, dla której producenci związani z EJB

nie zachęcają do takich rozwiązań).

Reasumując, wydaje mi się, że zastosowanie obiektów entity bean do implementacji modelu dziedziny

sprawdza się wtedy, gdy logika dziedziny jest tylko umiarkowanie rozbudowana. Wówczas model może

mieć prosty związek z bazą danych, oparty na ogólnej zasadzie przypisania jednej klasy entity bean do

jednej tabeli bazy danych. Bardziej rozbudowana logika, wykorzystująca dziedziczenie, strategie i inne

wyrafinowane wzorce, wymaga modelu opartego na obiektach POJO i wzorcu Data Mapper (152). Ten

ostatni możemy wygenerować korzystając ze specjalnego, zakupionego narzędzia.

Mnie osobiście najbardziej zniechęca do korzystania z EJB fakt, że rozbudowany model dziedziny

jest sam w sobie wystarczająco skomplikowany, aby skłaniać do utrzymywania jak największej nieza-

leżności od środowiska implementacji. EJB wymusza pewne schematy działania, co sprawia, że musi-

my zajmować się nie tylko dziedziną, ale i jednocześnie środowiskiem EJB.

Kiedy używamy

O ile odpowiedź na pytanie „jak” jest trudna ze względu na obszerność tematu, odpowiedź na py-tanie „kiedy” nie jest łatwa ze względu na swoją ogólność i prostotę. Sprowadza się bowiem dorozważenia poziomu złożoności funkcji systemu. Skomplikowane i zmienne reguły biznesowe,


obejmujące sprawdzanie poprawności, obliczenia i derywacje, zdecydowanie powinny skłaniać dozastosowania modelu obiektowego. Z drugiej strony, proste weryfikacje typu „not null” i oblicza-nie kilku podsumowań to zadanie idealne dla skryptów transakcji.

Jednym z czynników jest doświadczenie zespołu pracującego nad aplikacją, a konkretniej — jakradzi on sobie z operowaniem obiektami dziedziny. Projektowanie i praca z modelem dziedziny tocoś, czego trzeba się nauczyć. Stąd wiele artykułów opisujących tę „zmianę paradygmatu” w rozwią-zaniach obiektowych. Proces nauki jest długi, a zdobycie praktyki wymaga czasu. Ukoronowaniemnauki jest rzeczywista zmiana sposobu myślenia, kiedy projektant przestaje stosować inne wzorcewarstwy dziedziny i nie chce używać skryptów transakcji w żadnych aplikacjach poza, ewentualnie,najprostszymi.

Gdy stosujemy model dziedziny, podstawowym schematem interakcji z bazą danych jest Data

Mapper (152). Pomaga on utrzymać niezależność modelu od bazy i jest najlepszym podejściem,gdy model dziedziny i schemat bazy danych znacznie różnią się od siebie.

Uzupełnieniem modelu dziedziny może być warstwa usług (Service Layer (124)), zapewniającamodelowi przejrzysty interfejs API.

Warto przeczytać

Niemal każda książka traktująca o projektowaniu obiektowym porusza zagadnienie modeli dziedzi-ny. Decyduje o tym fakt, że w powszechnym rozumieniu programowanie obiektowe opiera sięwłaśnie na takim podejściu.

Czytelnikom poszukującym wprowadzenia do projektowania obiektowego polecam obecnieksiążkę Larman. Przykłady modelu dziedziny znajdziemy w Fowler AP. Hay zawiera wiele przykła-dów ukierunkowanych na kontekst relacyjny. Zbudowanie dobrego modelu dziedziny wymaga do-brej znajomości teorii projektowania obiektowego. Jest ona doskonale wyłożona w Martin and Odell.Wyczerpujący przegląd wzorców charakterystycznych dla rozbudowanych modeli dziedziny, a takżeinnych systemów obiektowych, znajdziemy w Gang of Four.

Eric Evans pisze obecnie książkę Evans, traktującą właśnie o budowaniu modeli dziedziny. Dochwili pisania tych słów miałem okazję zetknąć się tylko z jej wstępną wersją, ale wyglądała onabardzo obiecująco.


Opisywanie zasad modelowania dziedziny jest dość niewdzięcznym zajęciem, ponieważ każdyprzykład, który można przedstawić, jest z konieczności bardzo uproszczony. Uproszczenia te sku-tecznie ukrywają wszelkie mocne strony tego rodzaju rozwiązań. Można je naprawdę docenić tyl-ko wtedy, gdy rozpatrzymy naprawdę złożoną dziedzinę, na co oczywiście nie ma tu miejsca.

Choć przykład nie może być wystarczająco dobrym dowodem wielkich korzyści, jakie za-pewnia modelowanie dziedziny, może przynajmniej dać Czytelnikowi pewne pojęcie o tym, jaktaki model może wyglądać. Korzystam tutaj z tego samego przykładu (strona 105), który posłużyłdo zilustrowania wzorca Transaction Scripts (skryptów transakcji).

Pierwszą rzeczą, którą zauważymy, będzie to, że każda klasa obejmuje zarówno zachowania,jak i dane (patrz rysunek 9.3). Nawet prosta klasa �� !�� zawiera metodę służącą dookreślania, czy w danym dniu wartość obiektu została już zaksięgowana.


RYSUNEK 9.3. Diagram klas dla przykładu modelu dziedziny

�� !��,,,

��%�� 2��%(��2�� -�� !��%�� %(��0��,�� 1�� 2��,��1��2��6�� -��%��!�� 0�� 2��6��!��"�-��%(��#(��0�� #(,�(��GG��#(,�5 ��2��6

Obliczanie wielkości przychodu uznanego na dany dzień wymaga klas umowy i uznania przychodu.

��,,,

�� !��1��+��2


�� -��%��!��"�� %(��#(��0��%�� 1�%��,��>�2��1�� !��,��2��+��,��<�/��0�� !��1�� !��,��/��2��(��,��!��"�-��#(�� 1�� ,��,!�� 2��6�� 2��6

Charakterystyczny dla modelów dziedziny jest sposób, w jaki wiele klas współpracuje ze sobąw realizacji nawet najprostszych zadań. To właśnie prowadzi często do konkluzji, że w progra-mach obiektowych ogromną ilość czasu spędzamy na przeszukiwaniu kolejnych klas, szukając tej,która jest nam w danej chwili potrzebna. Konkluzja taka jest niewątpliwie słuszna. Wartość takie-go rozwiązania doceniamy, gdy decyzja o uznaniu przychodu w określonym dniu staje się bardziejskomplikowana. Musimy też rozważyć informacje dostępne dla innych obiektów. Zamknięcie za-chowania w obiekcie, który potrzebuje określonych danych, pozwala uniknąć powtórzeń kodu i ograni-cza sprzężenia między obiektami.

Analiza sposobu obliczania wartości i tworzenia obiektów reprezentujących uznanie przychodupozwala zauważyć charakterystyczne dla modelu dziedziny liczne obiekty o niewielkich rozmiarach.W przedstawionym przykładzie, obliczenia i tworzenie obiektu rozpoczynają się od klienta i sąprzekazywane poprzez produkt do hierarchii strategii. Wzorzec strategii Gang of Four to popular-ny wzorzec projektowania obiektowego, który umożliwia połączenie grupy operacji w hierarchięniewielkich klas. Każdy egzemplarz produktu jest połączony z pojedynczym egzemplarzem strategiiobliczania uznania, określającej, który algorytm zostanie użyty do obliczenia uznania. W tymprzypadku mamy dwie podklasy strategii obliczania uznania, reprezentujące dwa różne przypadki.Struktura kodu wygląda następująco:

��,,,

��$�� 2��%�� 2��%(��+�� !��2��!��2�� -��$�� %�� %(��+�� !��0��,�� 1�� 2��,�� 1�� 2��,+�� !��1�+�� !��2��6

��$�� ,,,

�� !��2��!�� !��!�� !�2�� -��$�� !��!�� !��!�� !��0��,��1��2��,��!�� !��1��!�� !�2��6


�� -��$�� +9��$�� !��0�� +�$�� +��!�� !��2��6�� -��$�� + �� !��0�� +�$�� +��9��!�� !��B>�C>��2��6�� -��$�� +��-�� !��0�� +�$�� +��9��!�� !��A>�B>��2��6

��!�� !�,,,

��-�� !��2

��!�� !�,,,

�� !��0��,�� !��+�� !��,!�� ,!��9�� !��2��6

��9��!�� !�,,,

��(��!��#((��2��!��#((��2�� -��9��!�� !��(��!��#((��!��#((��0��,(��!��#((��1�(��!��#((��2��,��!��#((��1��!��#((��2��6�� !��0��%��?@��1��,!�� ,��A�2��,�� !��+�� !��?>@��,!��9�� !��2��,�� !��+�� !��?3@��,!��9�� !��,��(��!��#((��2��,�� !��+�� !��?4@��,!��9�� !��,��!��#((��2��6

Wielką zaletą strategii jest to, że zapewniają dobrze zintegrowane punkty rozbudowy aplikacji.Dodawanie nowego algorytmu uznawania przychodu wymaga więc utworzenia nowej podklasy, z wła-sną metodą �� !��. Znacznie ułatwia to wprowadzanie do systemu nowychalgorytmów.

Gdy tworzymy obiekty reprezentujące produkty, łączymy je z odpowiednimi obiektami strategii.Implementuję to w kodzie testu.

��,,,

��$�� +��1�$�� ,��+9��$��7��!�9��7�2


��$�� 1�$�� ,��+ ��7��!��7�2��$�� -�1�$�� ,��+��-��7��!��7�2

Gdy wszystkie elementy są gotowe, obliczanie uznania przychodu nie wymaga znajomości podklasstrategii.

��,,,

�� -�� !��0�� ,�� !��2��6

��$�� ,,,

�� !��0��!�� !�,�� !��2��6

Obiektowa zasada przekazywania od obiektu do obiektu przenosi zachowanie do tego z nich,który jest najbardziej uprawniony do obsługi tego zachowania, a co więcej, realizuje większośćfunkcji warunkowych. Można zauważyć, że w obliczeniach nie ma żadnych instrukcji warunko-wych. Wprowadzony układ obiektów sprawia, że algorytmy w naturalny sposób podążają właściwąścieżką. Modele dziedziny sprawdzają się bardzo dobrze, gdy w systemie jest wiele podobnychwarunków, bo wówczas warunki te mogą zostać zrealizowane przez samą strukturę obiektów.Przenosi to złożoność z algorytmów do samych związków między obiektami. Im bardziej podobnalogika, tym częściej okazuje się, że ta sama sieć związków jest wykorzystywana przez różne częścisystemu. Każdy algorytm zależny od sposobu obliczania uznania przychodu może korzystać z wpro-wadzonego układu.

Pragnę zwrócić uwagę Czytelnika na fakt, że w tym przykładzie nie przedstawiam żadnegoopisu sposobów pobierania i zapisywania obiektów do bazy danych. Wynika to z kilku przyczyn.Po pierwsze, mapowanie modelu dziedziny do bazy danych jest dość skomplikowane, więc zwy-czajnie uciekam przed trudami tego opisu. Po drugie, samym celem wprowadzenia modelu dzie-dziny jest ukrycie bazy danych, tak przed warstwami wyższymi, jak i przed osobami, które pracująz modelem. Pominięcie opisu interakcji z bazą danych jest więc odbiciem tego, jak w rzeczywistościwygląda programowanie w środowisku opartym na wzorcu Domain Model.

TABLE MODULE (MODUŁ TABELI) 117

Table Module (moduł tabeli)

Pojedynczy egzemplarz obsługuje logikę biznesową

dla wszystkich wierszy tabelilub widoku bazy danych.

Jedną z podstawowych zasad podejścia obiektowego jest wiązanie danych z funkcjami (zachowa-niami), które na tych danych operują. Tradycyjny schemat opiera się na obiektach o określonejtożsamości. Rozwiązania tego rodzaju reprezentuje wzorzec Domain Model (109). Gdy więc mamydo czynienia z klasą Pracownik, każdy egzemplarz tej klasy odpowiada pewnemu pracownikowi.Systemy tego rodzaju sprawdzają się dobrze w praktyce, ponieważ posiadanie odwołania do pracow-nika umożliwia wykonywanie związanych z nim operacji, podążanie za odwołaniami i gromadze-nie danych o pracowniku.

Jednym z problemów charakterystycznych dla modelu dziedziny jest implementacja interfejsurelacyjnej bazy danych. Można powiedzieć, że baza relacyjna jest w takich rozwiązaniach jakciotka-wariatka, zamknięta na strychu i wspominana w rozmowach jak najrzadziej i tylko wtedy,kiedy jest to absolutnie konieczne. Wynikiem tego są niezwykłe akrobacje, do których programistajest zmuszony w sytuacji, kiedy pojawia się potrzeba pobrania lub zapisania danych w bazie. Trans-formacje pomiędzy dwiema reprezentacjami danych okazują się czasochłonnym i wymagającymfragmentem pracy nad aplikacją.

Gdy korzystamy ze wzorca Table Module, logika dziedziny zostaje uporządkowana w klasy,które odpowiadają poszczególnym tabelom bazy danych. Pojedynczy egzemplarz takiej klasy za-wiera różnorodne procedury operujące danymi tabeli. Głównym wyróżnikiem wzorca Domain

Model (109) jest to, że gdy mamy do czynienia z wieloma zamówieniami, jednemu zamówieniuodpowiada jeden obiekt zamówienia. Gdy korzystamy ze wzorca Table Module, jeden obiekt obsłu-guje wszystkie zamówienia.


Na czym polega

Zaletą wzorca Table Module jest to, że umożliwia połączenie ze sobą danych i zachowań bez utratywartości reprezentowanych przez relacyjną bazę danych. Z wierzchu moduł tabeli wygląda jakzwykły obiekt. Główną różnicą jest brak powiązania go z tożsamością bytów, na których operuje.Aby uzyskać adres pracownika, używamy metody w rodzaju �� $��+��,�-��"��!��$��+��. Za każdym razem, gdy zamierzamy wykonać operację na wybranym pracowniku,musimy przekazać pewnego rodzaju odwołanie do jego tożsamości. Najczęściej jest to klucz głównytabeli bazy danych.

Wzorzec Table Module stosujemy zazwyczaj z pewną strukturą składowania danych opartąna tabelach. Ułożone w tabele dane są najczęściej wynikiem wywołania SQL i są przechowywanew obiekcie Record Set (465), którego zachowania są podobne do zachowań tabeli SQL. Zadaniemmodułu tabeli jest zapewnienie interfejsu danych opartego na metodach. Grupowanie zachowańwedług tabel zapewnia wiele zalet hermetyzacji — funkcje pozostają blisko związane z danymi,na których operują.

Wykonanie pewnych operacji często wymaga użycia funkcji wielu modułów tabel. Niejedno-krotnie więc można się spotkać z wieloma modułami, które operują na tym samym obiekcie Record

Set (465) (patrz rysunek 9.4).

RYSUNEK 9.4. Kilka modułów tabeli może korzystać z tego samego obiektu Record Set (465)

Najbardziej przejrzystym przykładem rozwiązania opartego na modułach tabel będzie sytuacja,kiedy każdy z modułów odpowiada pojedynczej tabeli bazy danych. Jeżeli jednak w bazie danychzdefiniowane zostały pewne użyteczne zapytania i widoki, również i one mogą mieć własne moduły.

Moduł tabeli może być egzemplarzem klasy lub grupą metod statycznych. Zaletą stosowaniaegzemplarzy jest to, że można wówczas inicjalizować moduł tabeli przy użyciu zbioru rekordów(który może być wynikiem zapytania). Egzemplarz modułu służy w takiej sytuacji do wykonywaniaoperacji na wierszach zestawu rekordów. Egzemplarze pozwalają również korzystać z dziedziczenia,można więc stworzyć moduł dla wybranej grupy umów, który zawiera zachowania nie mające od-niesienia do każdej z nich.


Zapytania w module tabeli mogą przyjąć postać metod fabrykujących (ang. factory methods).Alternatywą jest wzorzec Table Data Gateway (133), choć wówczas w projekcie pojawia się do-datkowa klasa i związany z nią mechanizm. Zaletą takiego rozwiązania jest możliwość korzystaniaz pojedynczego modułu tabeli do obsługi danych z różnych źródeł, ponieważ każde z nich możeobsługiwać inna brama Table Data Gateway (133).

Gdy używamy bramy Table Data Gateway (133), aplikacja wykorzystuje ją przede wszystkimdo zbudowania obiektu Record Set (465). Obiekt ten staje się wówczas argumentem konstruktoramodułu tabeli. Gdy niezbędne jest wykorzystanie wielu modułów tabeli, można utworzyć je przyużyciu tego samego zestawu rekordów. Moduł tabeli realizuje wówczas operacje logiki biznesowej,po czym przekazuje zmodyfikowany obiekt Record Set (465) do warstwy prezentacji, która wy-świetla dane zestawu rekordów i umożliwia wprowadzanie zmian. W warstwie prezentacji możnawówczas stosować widżety dostosowane do operowania danymi tabel. Widżety te nie odróżniajązestawów rekordów pobranych bezpośrednio z relacyjnej bazy danych od tych, które zostały zmo-dyfikowane przez moduł tabeli. Po zmianach, wprowadzonych przy użyciu graficznego interfejsuużytkownika, dane powracają do modułu tabeli w celu sprawdzenia poprawności, po czym są za-pisywane w bazie danych. Jedną z zalet takiego podejścia jest możliwość testowania modułu tabeliprzez stworzenie obiektu Record Set (465) w pamięci, bez użycia bazy danych (rysunek 9.5).

RYSUNEK 9.5. Typowe interakcje warstw otaczających moduł tabeli

Słowo „tabela” w nazwie wzorca sugeruje powiązanie każdego modułu z pojedynczą tabeląbazy danych. Jest to zasadniczo prawdą, ale nie obowiązującą regułą. Można stosować moduły tabelidla bardziej znaczących widoków i innych zapytań. Struktura modułu tabeli nie jest ściśle uwa-runkowana strukturą tabel bazy. Można więc korzystać z tabel wirtualnych, które powinny byćwidoczne dla aplikacji, czyli właśnie widoków i zapytań.


Kiedy używamy

Wzorzec Table Module opiera się na danych uporządkowanych w tabele. Korzystanie z niego jestuzasadnione, gdy korzystamy z takich danych przy użyciu obiektów Record Set (465). Obiektytakie stają się osią kodu aplikacji, więc dostęp do nich musi być stosunkowo prosty.

Wzorzec Table Module nie zapewnia pełnego wykorzystania koncepcji programowania obiek-towego przy dobrze uporządkowanej, złożonej logice aplikacji. Nie można tworzyć bezpośrednichrelacji między egzemplarzami obiektów. Polimorfizm również nie sprawdza się w takich rozwią-zaniach. Gdy poziom złożoności jest duży, budowanie modelu dziedziny będzie lepszym podej-ściem. Wybór pomiędzy wzorcami Table Module a Domain Model (109) sprowadza się w zasadziedo wyboru pomiędzy potencjałem obsługi bardzo złożonej logiki a prostotą integracji z opartymina tabelach strukturami danych.

Jeżeli obiekty modelu dziedziny i tabele bazy danych mogą opierać się na podobnej organizacji,warto rozważyć połączenie wzorca Domain Model (109) z obiektami Active Record (147). Zaletymodułów tabeli przewyższają korzyści z takiej kombinacji w sytuacji, gdy inne części aplikacjikorzystają ze wspólnej, tabelarycznej struktury danych. Stąd bierze się niewielka popularnośćwzorca Table Module (117) w środowisku Java. I to jednak może się zmienić wraz z coraz szer-szym stosowaniem mechanizmu zestawów wierszy (ang. row set).

Najczęściej spotykanym zastosowaniem wzorca Table Module są projekty oparte na mechani-zmach Microsoft COM. W środowisku COM (i .NET) zestaw rekordów (Record Set (465)) jestpodstawowym typem repozytorium danych aplikacji. Zestawy rekordów mogą być przekazywanedo interfejsu użytkownika, gdzie specjalne widżety wyświetlają zawarte w nich dane. BibliotekiMicrosoft ADO zapewniają niezbędny mechanizm dostępu do danych struktur relacyjnych. W takimśrodowisku moduły tabeli umożliwiają efektywne porządkowanie logiki biznesowej bez utratyułatwień w obsłudze tabel, jakie zapewniają różne dostępne programiście aplikacji elementy.

Przykład: uznanie przychodu (C#)

Pora powrócić do przykładu aplikacji obliczającej uznania przychodu (opis na stronie 105), którejimplementacje służyły nam do zilustrowania wcześniej omawianych wzorców warstwy dziedziny.Dla przypomnienia, celem jest tu obliczenie uznania przychodu dla zamówień w sytuacji, gdy re-guły obliczania różnią się w zależności od produktu, którego dane uznanie dotyczy. Mamy doczynienia z trzema produktami: edytorami tekstu, arkuszami kalkulacyjnymi i bazami danych.

System modułów tabeli opiera się na pewnym schemacie danych, który zazwyczaj jest mode-lem relacyjnym (chociaż w przyszłości w podobnych schematach spotkamy się zapewne z mo-delami XML). W tym przypadku podstawą jest schemat relacyjny przedstawiony na rysunku 9.6.

RYSUNEK 9.6. Schemat bazy danych dla przykładu obliczania uznań przychodu


Klasy operujące danymi uporządkowane są bardzo podobnie; każdej tabeli odpowiada jedenmoduł tabeli. W architekturze .NET reprezentację struktury bazy danych w pamięci zapewniaobiekt zbioru danych (ang. data set). Właśnie na takich obiektach powinny operować tworzoneklasy. Każda klasa modułu tabeli ma pole typu ��-��. Jest to klasa, która w systemie .NETodpowiada pojedynczej tabeli zbioru danych. Mogą z niej korzystać wszystkie moduły tabeli i możnają traktować jako wzorzec Layer Supertype (434).

��-��%�� ,,,

��-��-��2��-��%�� !��-��<��0��-��1��,��-��?��-��<��@2��6

Konstruktor podklasy wywołuje konstruktor superklasy korzystając ze wskazanej nazwy tabeli.

��,,,

�� -�� H�-��7��7��06

Umożliwia to utworzenie nowego modułu tabeli przez proste przekazanie zbioru danych do kon-struktora modułu.

��1��+��2

Utrzymujemy w ten sposób kod odpowiedzialny za tworzenie zbioru danych poza modułami tabe-li, co odpowiada zasadom korzystania z ADO.NET.

Wygodną cechą języka C# jest indeksator (ang. indexer), który umożliwia dostęp do wybranegowiersza danych tabeli w oparciu o klucz główny.

��,,,

�� -��+��?��!��@�0��!��0�� !�(��1� ��!,)��7��1�0>67��2�� -��, ��(��?>@2��6��6

Pierwszy fragment kodu, w którym implementujemy zachowania, oblicza uznanie przychodudla umowy, aktualizując odpowiednio tabelę uznań. Uznawana kwota zależy od produktu, któregodotyczy. Ponieważ korzystamy przy tym głównie z danych tabeli umów, włączamy odpowiedniąmetodę do klasy umów.

��,,,

�� -�� !��!��0��+��+�1��?��@2�� 1��+?7�� 7@2�� !��1��+�� !��-��,�� 2��$�� 1��+�$�� -��,�� 2��!��1�*��$�� 2


��(��,*��$�� 11�$�� ,9$��0��,�� *��9�� !��2��6��(��,*��$�� 11�$�� , ��0��?@��1�� A�2��,��?>@��*��9�� !��2��,��?3@��*��9�� !��,��B>��2��,��?4@��*��9�� !��,��C>��2��6��(��,*��$�� 11�$�� ,��0��?@��1�� A�2��,��?>@��*��9�� !��2��,��?3@��*��9�� !��,��A>��2��,��?4@��*��9�� !��,��B>��2��6��+��+��/��7��"��(�� 7�2��6��?@�� -��0��+�� 1�� I�-�2��+�� 1��,�� +�� 4�2��!�� 1��+�� 8�>,>3�2��?@�� 1��+��?-�@2��1�� J�-�2��(��1�>2��=��2��88�� ?�@�1��!�� 2��(��1��2��=�-�2��88�� ?�@�1��+�� 2�� 2��6

Choć we wcześniejszych przykładach używałem w tym miejscu obiektu Money (446), tutaj dlazróżnicowania wprowadziłem typ ��. Metoda alokacji jest podobna jak w przypadku klasyMoney (446).

Do przeprowadzenia takich operacji niezbędne są pewne funkcje zdefiniowane w innych kla-sach. Musimy mieć możliwość pobrania typu każdego produktu. Możliwość tę zapewnimy sobie,wprowadzając enumerację typów i metodę pobierającą odpowiednią wartość.

�� -�� $�� 09$�� 62

��$�� ,,,

�� -��$�� *��$�� !��0�� !��1�� !��?��@?7��7@2�� $�� ,$��(�$�� 2��6

Metoda *��$�� hermetyzuje dane tabeli. Ogólnie rzecz biorąc, bezpośredni odczyt sumyumowy z kolumny tabeli (jak w przykładzie powyżej) nie jest najlepszym podejściem. Zasadahermetyzacji powinna objąć poszczególne kolumny danych. Rozwiązanie takie wybrałem ze względuna założenie, że pracujemy w środowisku, w którym różne części systemu korzystają z bezpośredniegodostępu do zbioru danych. Gdy zbiór danych jest przekazywany do interfejsu użytkownika, hermety-zacja również nie jest stosowana. Funkcje dostępu do kolumn stosujemy tylko wtedy, gdy ma tosłużyć wprowadzeniu dodatkowej funkcjonalności, takiej jak konwersja ciągu na typ $�� .


Warto w tym miejscu wspomnieć również o tym, że choć w przykładzie stosujemy zbiór danycho nieokreślonych typach (ponieważ jest to częściej stosowane na różnych innych platformach),w środowisku .NET zaleca się ścisłe określanie typów (strona 466).

Kolejną niezbędną funkcją jest wstawianie nowego rekordu uznania przychodu.

�� !��,,,

�� -��!��!�� 0��+��+��+�1��-��,<�+��+��2��!��1�*��<�/��2��+��+?7��7@�1��2��+��+?7��7@�1��2��+��+?7�� 7@�1�� 2��+��+?7��7@�1� ��!,)��70>H�67��2��-��,��+�,��+��+�2�� 2��6

Również ta metoda służy nie tyle hermetyzacji wiersza danych, co przede wszystkim wprowadzeniumetody w miejsce kilku wierszy kodu, które musiałyby być powtarzane w różnych miejscach aplikacji.

Drugą funkcją jest sumowanie wszystkich przychodów umowy uznanych do określonego dnia.Ponieważ korzysta ona z tabeli uznań przychodów, metodę definiujemy w odpowiadającej tej tabeliklasie.

�� !��,,,

�� -��!��"�� !��#(��0�� !�(��1� ��!,)��7��1�0>6��<��=1�K03H�6K7��#(�2��+?@��+��1��-��, ��(��2�� 1�>�2��(��+��+��+��0�� 81��+?7�� 7@2��6�� 2��6

Ten fragment korzysta z bardzo wygodnego mechanizmu ADO.NET, który umożliwia (bez użyciajęzyka SQL) definiowanie klauzuli 9:�� i wybieranie podzbioru danych tabeli, na których majązostać wykonane operacje. W praktyce, w tak prostym przykładzie można pójść jeszcze dalej i użyćfunkcji agregującej.

�� !��,,,

�� -��!��"�� 4��!��#(��0�� !�(��1� ��!,)��7��1�0>6��<��=1�K03H�6K7��#(�2�� !�� /��1�7� �� 72��#-L�� 1��-��,�� /��(��2�� ,��< ��;�>�H�� 2��6


Service Layer (warstwa usług)Randy Stafford

Definiuje granicę aplikacji przez wprowadzenie warstwy, która określa zbiór dostępnychoperacji i koordynuje odpowiedzi aplikacji dla każdej z nich.

Aplikacje dla przedsiębiorstw wymagają często różnych interfejsów danych, na których operują,i logiki, którą implementują: mechanizmów ładowania danych, interfejsów użytkownika, bramintegracji i innych. Pomimo, że są przeznaczone do różnych celów, interfejsy te często wymagajątych samych mechanizmów interakcji z aplikacją, niezbędnych, aby uzyskać dostęp i operowaćdanymi, jak również do wywoływania funkcji logiki biznesowej. Interakcje te mogą być bardzozłożone, mogą obejmować transakcje operujące na różnych zasobach i wymagać koordynacji wieluodpowiedzi aplikacji na pojedyncze wywołanie. Kodowanie logiki interakcji w każdym z interfejsówniezależnie prowadzi wówczas do znacznej ilości powtórzeń.

Warstwa usług definiuje granicę aplikacji Cockburn PloP i zbiór operacji dostępnych war-stwom klienckim. Hermetyzuje ona logikę biznesową, zapewniając sterowanie transakcjami i koor-dynację odpowiedzi aplikacji, generowane przez właściwe implementacje operacji.

SERVICE LAYER (WARSTWA USŁUG) 125

Na czym polega

Warstwa usług może być implementowana kilkoma sposobami, z których każdy odpowiada przed-stawionej powyżej charakterystyce. Różnice występują w podziale funkcjonalności wspierającejinterfejs tej warstwy. Zanim przedstawię bliżej różne możliwości implementacji, zapoznajmy sięz podstawą koncepcyjną wzorca Service Layer.

Typy logiki biznesowej

Podobnie jak Transaction Script (103) i Domain Model (109), wzorzec Service Layer (124)służy do porządkowania logiki biznesowej. Wielu projektantów — wśród nich i ja — dzieli logikębiznesową (ang. business logic) na dwa rodzaje: logikę dziedziny (ang. domain logic), związanąwyłącznie z dziedziną problemu (jak strategie obliczania uznania przychodu z umowy), i logikęaplikacji (ang. application logic), związaną z funkcjami aplikacji Cockburn UC (jak powiadamia-nie administratorów umów i aplikacji zintegrowanych o obliczeniach uznań przychodu). Logikęaplikacji określa się czasem terminem „logika pracy” (ang. workflow logic), choć termin „praca”(albo „przepływ pracy”) bywa różnorodnie interpretowany.

Model dziedziny ma tę przewagę na skryptami transakcji, że dzięki zastosowaniu klasycz-nych wzorców projektowych sprzyja unikaniu duplikacji kodu dziedziny i ułatwia zarządzaniezłożonością. Jednak umieszczenie logiki aplikacji w klasach obiektów dziedziny ma kilka niepo-żądanych konsekwencji. Po pierwsze, klasy obiektów dziedziny, które zawierają logikę specy-ficzną dla określonej aplikacji i są zależne od jej pakietów, nie mogą być używane w innych apli-kacjach. Po drugie, połączenie obu rodzajów logiki w tych samych klasach utrudnia powtórnezaimplementowanie, gdy przyjdzie taka potrzeba, logiki aplikacji (na przykład w narzędziu do za-rządzania przepływem pracy). Wprowadzenie warstwy usług umożliwia oddzielenie dwóch ro-dzajów logiki biznesowej. Oznacza to nie tylko korzyści typowe dla podziału warstwowego apli-kacji, ale również czyste klasy obiektów dziedziny, które łatwiej przenosić między aplikacjami.

Możliwości implementacji

Dwie podstawowe opcje implementacji to fasada dziedziny i skrypty operacji. Fasada dzie-

dziny (ang. domain facade) to zbiór prostych osłon modelu dziedziny. Implementujące je klasynie zawierają logiki biznesowej, która w całości pozostaje w modelu dziedziny. Osłony wyzna-czają granicę aplikacji i zbiór operacji, które warstwy klienckie mogą wykorzystywać do interakcjiz nią.

Skrypty operacji (ang. operation script) to zbiór nieco bardziej rozbudowanych klas, którebezpośrednio implementują logikę aplikacji, delegując zarazem logikę dziedziny do hermetycz-nych klas obiektów dziedziny. Operacje dostępne klientom warstwy usług są implementowane ja-ko skrypty uporządkowane według obszarów tematycznych logiki. Każda taka klasa stanowi„usługę” aplikacji, stąd często umieszczane w ich nazwach słowo „Service” (usługa). Zbiór takichklas tworzy warstwę usług. Powinny one być rozszerzeniem klasy Layer Supertype (434), któraogólnie definiuje zakres ich funkcji i wspólne zachowania.

Wywołania zdalne

Interfejs warstwy usług ma niską ziarnistość. Wynika to w oczywisty sposób stąd, że jest tozestaw operacji aplikacji, które są dostępne dla korzystających z niej warstw klienckim. W konse-kwencji, klasy warstwy usług dość dobrze nadają się do realizacji wywołań zdalnych.

Z drugiej strony, zdalne wywołania wiążą się z kosztem rozproszenia obiektów. Wprowadze-nie do warstwy usług obiektów Data Transfer Object (366) wymaga zazwyczaj dość dużo pracy.Ten dodatkowy koszt warto potraktować poważnie, zwłaszcza gdy model dziedziny jest skompliko-wany, a interfejs użytkownika rozbudowany pod kątem obsługi złożonych przypadków aktualizacji


danych. Jest to praca znacząca i czasochłonna, porównywalna chyba tylko z mapowaniem obiek-towo-relacyjnym. Nigdy nie wolno więc zapominać o „pierwszym prawie projektowania dla obiek-tów rozproszonych” (strona 87).

Najrozsądniejszym podejściem do budowy warstwy usług będzie więc stworzenie metodprzeznaczonych do wywołań lokalnych, których sygnatury operują obiektami dziedziny. Możli-wość wywołań zdalnych można dodać dopiero wtedy, gdy okaże się faktycznie niezbędna. Korzy-stamy wówczas ze wzorca Remote Facade (353), który uzupełnia gotową warstwę, przystosowanądo użytku lokalnego (można też wprowadzić interfejsy zdalne bezpośrednio do obiektów warstwyusług). Jeżeli aplikacja jest wyposażona w interfejs przeglądarki WWW lub usług WWW, nieoznacza to jeszcze, że logika biznesowa musi pracować w innym procesie niż strony serwera czyusługi sieci Web. W rzeczywistości, można oszczędzić sobie pracy i skrócić czas reakcji aplikacjistosując rozwiązanie kolokowane. Nie oznacza to wcale ograniczenia skalowalności.

Identyfikacja usług i operacjiIdentyfikowanie operacji, które powinna zapewniać wyznaczana przez warstwę usług grani-

ca, jest stosunkowo proste. Wyznaczają je potrzeby klientów, z których najbardziej znaczącym(i pierwszym) jest najczęściej interfejs użytkownika. Ponieważ jest on zaprojektowany pod kątemprzypadków użycia, punktami wyjścia stają się potrzeby aktorów, opracowane wcześniej przypad-ki użycia i projekt interfejsu użytkownika aplikacji.

Wiele przypadków użycia aplikacji korporacyjnej to dość nudne operacje „utwórz”, „odczytaj”,„aktualizuj”, „usuń” — dla różnych obiektów dziedziny. Tworzymy więc jeden obiekt pewnegorodzaju, odczytujemy kolekcję innych, aktualizujemy jeszcze inne itp. Doświadczenie wykazuje,że właśnie takie przypadki użycia mają swoje miejsce jako wzór dla funkcji warstwy usług.

Choć przypadki użycia prezentują się stosunkowo prosto, niezbędne do ich realizacji czynnościaplikacji są zazwyczaj znacznie ciekawsze. Poza sprawdzaniem poprawności danych oraz tworzeniem,aktualizowaniem i usuwaniem obiektów dziedziny, coraz częściej wymagane jest powiadamianie o wy-konanych operacjach zarówno osób, jak i innych aplikacji. Tego rodzaju zdarzenia wymagają ko-ordynacji i całościowego podejścia do ich przetwarzania. To właśnie jest zadaniem warstwy usług.

Nie jest łatwo wyznaczyć zasady grupowania powiązanych operacji warstwy usług. Trudnotu mówić o gotowych regułach postępowania. W przypadku niewielkiej aplikacji wystarczyć możejedna taka grupa, nazwana tak samo jak aplikacja. Większe aplikacje dzieli się na kilka „podsys-temów”, z których każdy zawiera kompletny „pion” elementów poszczególnych warstw architek-tury. W takim przypadku każdemu podsystemowi można przypisać jedną abstrakcję warstwyusług, dziedziczącą nazwę po podsystemie, do którego dostęp zapewnia. Alternatywą może byćgrupowanie według partycji modelu dziedziny (np. �� , $�� ) albo za-gadnień, z którymi związane są realizowane zachowania (np. ��!�� ).

Implementacja w języku Java

Zarówno fasada dziedziny, jak i skrypty operacji mogą być implementowane przy użyciu obiektów POJOlub bezstanowych obiektów bean sesji. Wybieramy tutaj pomiędzy łatwością testowania a łatwością

sterowania transakcjami. Zwykłe obiekty języka Java jest łatwiej testować, ponieważ nie wymagają dopracy kontenera EJB. Trudniej je natomiast powiązać z rozproszonymi, zarządzanymi kontenerowo

usługami transakcji, zwłaszcza przy wywołaniach pomiędzy usługami. Obiekty EJB zapewniają obsługękontenerowo zarządzanych transakcji rozproszonych, ale każde uruchomienie lub test musi odbywać się

w środowisku kontenera. Wybór nie jest więc łatwy.Moją ulubioną techniką implementacji warstwy usług w J2EE są bezstanowe obiekty session be-

an EJB 2.0, wyposażone w interfejsy lokalne. Korzystam przy tym ze skryptów operacji, które delegujądo klas obiektów dziedziny, zaimplementowanych jako obiekty POJO. Rozproszone, zarządzanekontenerowo transakcje, jakie zapewnia środowisko EJB, znakomicie ułatwiają implementowanie

warstwy usług przy użyciu bezstanowych obiektów session bean. Wprowadzone w EJB 2.0 interfejsylokalne umożliwiają warstwie usług wykorzystanie cennych usług transakcji, nie zmuszając zarazem do

wprowadzania obiektów rozproszonych.


Omawiając implementację w języku Java, warto zwrócić uwagę na różnice między wzorcem Service

Layer a wzorcem Session Facade, opisywanym w literaturze J2EE (Alur et al. i Marinescu). Session

Facade ma na celu uniknięcie obniżenia wydajności, wynikającego z nadmiernej liczby zdalnych wy-

wołań obiektów entity bean. Stąd osłonięcie obiektów entity bean obiektami session bean. Service Layer to

wzorzec, który dzieli implementację w celu uniknięcia powtórzeń kodu i ułatwienia jego powtórnego

użycia. Jest to wzorzec architektury niezależny od wykorzystywanej technologii. Warto przypomnieć,

że opisany w Cockburn PloP wzorzec granicy aplikacji, który był inspiracją dla wzorca Service Layer,

powstał trzy lata wcześniej niż środowisko EJB. Wzorzec Session Facade może przypominać w swojej

idei warstwę usług, nie jest jednak tym samym.

Kiedy używamy

Podstawowe korzyści z wprowadzenia warstwy usług to definicja jednolitego zbioru operacji aplikacji,który jest dostępny wielu rodzajom klientów, oraz koordynacja odpowiedzi aplikacji. Odpowiedźtaka może wymagać logiki aplikacji, która zapewnia całościowe przetwarzanie operacji, oparte nawielu zasobach transakcyjnych. Aplikacja, która ma więcej niż jednego klienta korzystającego z jejlogiki biznesowej, i realizuje złożone odpowiedzi oparte na wielu zasobach transakcyjnych, jestniewątpliwie dobrym kandydatem do wprowadzenia warstwy usług z kontenerowo zarządzanymitransakcjami, nawet jeżeli nie korzysta z architektury rozproszonej.

Prościej jest prawdopodobnie odpowiedzieć na pytanie, kiedy nie warto wprowadzać warstwyusług. Nie jest ona zazwyczaj uzasadniona, gdy logika biznesowa aplikacji ma tylko jednego klienta,na przykład interfejs użytkownika, a jej przypadki użycia nie przewidują korzystania z wielu zasobówtransakcyjnych. W takich przypadkach do kontroli transakcji i koordynowania odpowiedzi może posłu-żyć mechanizm Page Controller (302). Może on też delegować bezpośrednio do warstwy źródła danych.

Gdy tylko pojawia się koncepcja wprowadzenia drugiego klienta lub drugiego zasobu trans-akcyjnego, warto wprowadzić warstwę usług już na początku projektu.

Warto przeczytać

Niewiele napisano dotąd o wzorcu Service Layer (124). Jego pierwowzorem był wzorzec granicyaplikacji, przedstawiony przez Alistair Cockburn (Cockburn PloP). Praca Alpert et al. omawia rolęfasad w systemach rozproszonych. Dla porównania warto zapoznać się z różnymi opisami wzorcaSession Facade — Alur et al. i Marinescu. Z zagadnieniem funkcji aplikacji, które muszą być ko-ordynowane przez warstwę usług, powiązany jest opis przypadków użycia jako kontraktu zacho-wań, przedstawiony w Cockburn UC. Wcześniejszą pracą teoretyczną jest Coleman et al., gdziemowa o rozpoznawaniu „operacji systemowych” w metodologii Fusion.


Przedstawię teraz kolejną wersję przykładu, który służy nam jako ilustracja od początku rozdziału.Tym razem zaprezentuję na nim zastosowanie wzorca Service Layer, a więc podział na logikęaplikacji i logikę dziedziny. Warstwa usług będzie miała postać skryptu operacji, który zaimple-mentujemy najpierw przy użyciu obiektów POJO, a następnie obiektów EJB.


Rozwiniemy teraz nieco podstawowy scenariusz, aby wprowadzić do niego elementy logikiaplikacji. Załóżmy, że przypadki użycia aplikacji wymagają, aby obliczaniu uznań przychodu dlaumowy towarzyszyło przesłanie powiadomienia e-mail do wskazanego „administratora umów”oraz opublikowanie przy użyciu oprogramowania typu middleware wiadomości, która zapewniprzekazanie informacji aplikacjom zintegrowanym.

Rozpoczynamy od zmodyfikowania klasy ��!�� z przykładu ilustrującegowzorzec Transaction Script (103) tak, aby rozszerzyć klasę Layer Supertype (434) i wprowadzićkilka klas Gateway (425), które posłużą do realizacji logiki aplikacji. Będzie to odpowiadać dia-gramowi klas przedstawionemu na rysunku 9.7. Klasa ��!�� stanie się implementa-cją warstwy usług opartą na obiektach POJO, a jej metody będą reprezentować dwie dostępne nagranicy aplikacji operacje.

Metody klasy ��!�� realizują logikę aplikacji, delegując logikę dziedziny do klasobiektów dziedziny, wziętych z przykładu ilustrującego wzorzec Domain Model (109).

�� -�� 0��*��+��!��*��+��0��//zwraca egzemplarz bramy poczty elektronicznej

��6��!��*��+��!��!��*��+��0��//zwraca egzemplarz bramy integracji

��6��6�� -��(��*��+��0��%��!�� !�� !�� -L�� !�-��2��6�� -��(��!��*��+��0�� -�� !�� 2��6�� -��!�� /�� 0�� -�� !��!��< �-��0��1��,��)�E��< �-��2��,�� !��2��!��*��+��,��%��!��,!��7#�H�E��+��K7�8��< �-��8�7,�#-��"�� "��"�� ,7�2��!��!��*��+��, -�� !�� 2��6�� -��%��!��"�� !��< �-��#(��0�� ,��< �-��,��!��"�� #(�2��6��6

W naszym przykładzie nie będziemy zajmować się kwestiami magazynowania danych, ograni-czając się do stwierdzenia, że klasa �� implementuje statyczne metody do odczytywaniaumów z warstwy źródła danych według ich numerów. Nazwa jednej z tych metod (��)�E��) sy-gnalizuje zamiar aktualizacji odczytywanej umowy, co umożliwia mechanizmowi Data Mapper (152)zarejestrowanie odczytywanego obiektu przy użyciu, na przykład, schematu Unit of Work (169).


RYSUNEK 9.7. Diagram klas POJO dla usługi obliczania uznań przychodu


Nie będziemy również opisywać szerzej sterowania transakcjami. Metoda �� !�� jest z natury transakcyjna, ponieważ w trakcie jej wykonywania modyfikowane sątrwałe obiekty umów (przed dodaniem uznań przychodu); do oprogramowania middleware przeka-zywane są wiadomości; wysyłane są wiadomości pocztowe. Wszystkie te odpowiedzi aplikacjimuszą być przetwarzane jako całość, bo nie chcemy wysyłać wiadomości e-mail lub publikowaćwiadomości dla innych aplikacji, jeżeli zmiany w umowie nie zostały trwale zapisane.

Na platformie J2EE zarządzanie transakcjami rozproszonymi można pozostawić kontene-rowi EJB. W tym celu implementujemy usługi aplikacji (i obiekty Gateway (425)) jako bezsta-nowe obiekty session bean, korzystające z zasobów transakcyjnych. Rysunek 9.8 przedstawiadiagram klas implementacji usługi obliczania uznań przychodu, korzystającej z interfejsów lo-kalnych EJB 2.0 i idiomu „interfejsu biznesowego” (ang. business interface). W tej implementacjiwciąż korzystamy z klasy Layer Supertype (434), zapewniającej metody obiektów bean, którychwymaga mechanizm EJB, oraz metody specyficzne dla aplikacji. Jeżeli założymy, że interfejsy��*��+�� i ��!��*��+�� są również „interfejsami biznesowymi” odpowiednich bez-stanowych obiektów session bean, to sterowanie transakcją rozproszoną uzyskamy przez zade-klarowanie metod �� !��, ��%��!� i -�� !�� jako transakcyjnych. Metody ��!�� z przykładu opartego na obiektachPOJO zostają przeniesione w niezmienionej postaci do klasy ��!�� .

Ważnym elementem w tym przykładzie jest fakt, że warstwa usług używa do koordynowaniatransakcyjnych odpowiedzi aplikacji zarówno skryptów operacji, jak i klas obiektów dziedziny.Metoda �� !�� realizuje logikę aplikacji wymaganą przez przypadki uży-cia, ale deleguje logikę dziedziny do klas obiektów dziedziny. Zastosowanych jest też kilka tech-nik unikania powtórzeń kodu w skryptach operacji, które tworzą warstwę usług. Część funkcji jestprzeniesiona do osobnych obiektów Gateway (425), które mogą być ponownie wykorzystywaneprzez zastosowanie delegacji. Layer Supertype (434) zapewnia wygodny dostęp do tych obiektów.

Czytelnik mógłby stwierdzić, że zastosowanie wzorca Observer i Gang of Four pozwalałobyuzyskać bardziej elegancką implementację skryptu operacji. Jednak wzorzec Observer byłby trudnydo zaimplementowania w bezstanowej i wielowątkowej warstwie usług. Otwarty kod skryptu operacjiokazuje się bardziej przejrzysty i prostszy.

Można również stwierdzić, że funkcje logiki aplikacji mogłyby zostać zaimplementowane w me-todach obiektów dziedziny, takich jak ��,�� !��, lub nawet w war-stwie źródła danych, co wyeliminowałoby potrzebę stosowania osobnej warstwy usług. Taka alokacjafunkcji wydaje się jednak niepożądana z kilku powodów. Po pierwsze, klasy obiektów dziedzinygorzej poddają się próbom ponownego użycia w innych aplikacjach, gdy zawierają logikę specy-ficzną dla jednego rozwiązania (i pozostają zależne od specyficznych dla aplikacji obiektów (Gate-

way (425)). Ich zadaniem jest modelowanie części dziedziny problemu, z którymi aplikacja jestzwiązana, co jednak nie oznacza wszystkich funkcji wyznaczanych przez przypadki użycia tejżeaplikacji. Po drugie, hermetyzacja logiki aplikacji w „wyższej”, przeznaczonej wyłącznie do tegocelu warstwie (czego nie można powiedzieć o warstwie źródła danych) ułatwia wprowadzanie w niejzmian. Ich celem może być choćby wprowadzenie motoru zarządzania przepływem pracy.

Jako wzorzec organizacji warstwy logicznej aplikacji korporacyjnej, Service Layer łączy w so-bie skrypty i klasy obiektów dziedziny, korzystając z najlepszych cech obu podejść. Jego implemen-tacja może być przeprowadzona różnymi metodami: przy użyciu fasad dziedziny lub skryptówoperacji, obiektów POJO lub obiektów bean sesji (albo jednych i drugich), z orientacją na wywołanialokalne lub zdalne (albo oba rodzaje). Co najważniejsze, niezależnie od tego, którą implementacjęwybierzemy, będzie ona hermetyczną realizacją logiki biznesowej aplikacji, zapewniającą spójnyinterfejs tej logiki różnym warstwom klienckim.


RYSUNEK 9.8. Diagram klas EJB dla usługi obliczania uznań przychodu

architektura systemów zarządzania przedsiębiorstwem. wzorce projektowe

Technology