Architektura Systemów Zarządzania Przedsiębiorstwem. Wzorce Projektowe

IDZ DO
PRZYKADOWY ROZDZIA
SPIS TRECI
KATALOG KSIEK
KATALOG ONLINE
ZAMW DRUKOWANY KATALOG
TWJ KOSZYK
DODAJ DO KOSZYKA
CENNIK I INFORMACJE
ZAMW INFORMACJE
O NOWOCIACH
ZAMW CENNIK
CZYTELNIA
FRAGMENTY KSIEK ONLINE
Wydawnictwo Helion
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl
Architektura systemw
zarzdzania przedsibiorstwem.
Wzorce projektowe
Autor: Martin Fowler
Tumaczenie: Pawe Koronkiewicz (wstp, rozdz. 1 12),
Piotr Rajca (rozdz. 13 18, dod. A)
ISBN: 83-7361-715-9
Tytu oryginau: Patterns of Enterprise Application Architecture
Format: B5, stron: 496
Wykorzystaj wzorce projektowe w pracy nad oprogramowaniem

Zaprojektuj aplikacje o architekturze trjwarstwowej
Dobierz odpowiedni technologi
Stwrz moduy aplikacji
Systemy informatyczne suce do zarzdzania przedsibiorstwem to zwykle ogromne
aplikacje. Operuj na milionach rekordw, przesyaj gigabajty danych i s obsugiwane
przez dziesitki uytkownikw. Sprawne dziaanie takiej aplikacji jest niezwykle istotne
dla funkcjonowania przedsibiorstwa, dlatego musi ona by stabilna, a przed
wdroeniem -- gruntownie przetestowana. Przy tworzeniu aplikacji tego typu
wykorzystuje si opracowane ju rozwizania, zwane wzorcami projektowymi.
Wzorce projektowe to modele poszczeglnych komponentw aplikacji naley
jedynie zaimplementowa je w wybranym jzyku programowania.
Ksika Architektura systemw zarzdzania przedsibiorstwem. Wzorce projektowe
to przegld wzorcw wykorzystywanych przy projektowaniu aplikacji korporacyjnych.
Opisuje zasady podziau aplikacji na warstwy i zasady wsppracy pomidzy warstwami;
przedstawia take modele komponentw wchodzcych w skad kadej z nich.
Warstwy w aplikacjach biznesowych
Wzorce logiki aplikacji
Wzorce architektury rda danych
Wzorce mapowania obiektowo-relacyjnego
Wzorce prezentacji
Wzorce dystrybucji
Wzorce stanu sesji
Wzorce podstawowe
Korzystajc z zawartych w ksice wzorcw,

stworzysz stabilne i wydajne aplikacje korporacyjne.
Spis treci
Przedmowa.............................................................................................................13
Wstp .....................................................................................................................19
Architektura .....................................................................................................................................................19
Aplikacje korporacyjne ....................................................................................................................................20
Rodzaje aplikacji dla przedsibiorstw..............................................................................................................22
Wydajno .......................................................................................................................................................23
Wzorce .............................................................................................................................................................25
Struktura opisu wzorcw ...........................................................................................................................27
Ograniczenia wzorcw projektowych........................................................................................................28
Cz I Wprowadzenie
29
1.
Warstwy aplikacji ..................................................................................................31
Podzia warstwowy w aplikacjach dla przedsibiorstw....................................................................................32
Trzy gwne warstwy.......................................................................................................................................33
Ukad warstw ...................................................................................................................................................35
2.
Porzdkowanie logiki dziedziny ............................................................................37
Wybr wzorca..................................................................................................................................................40
Warstwa usug..................................................................................................................................................42
3.
Mapowanie do relacyjnych baz danych.................................................................43
Wzorce architektury.........................................................................................................................................43
Problem zachowa ...........................................................................................................................................47
Odczyt danych .................................................................................................................................................48
SPIS TRECI
Wzorce mapowania struktury...........................................................................................................................49

Mapowanie relacji .....................................................................................................................................49
Dziedziczenie.............................................................................................................................................52
Proces budowy mapowania..............................................................................................................................54
Podwjne mapowanie ................................................................................................................................55
Metadane..........................................................................................................................................................55
Poczenie z baz danych.................................................................................................................................56
Inne problemy mapowania...............................................................................................................................58
Warto przeczyta .............................................................................................................................................58
4.
Prezentacja w sieci WWW ....................................................................................59
Wzorce widoku ................................................................................................................................................62
Wzorce kontrolera danych wejciowych..........................................................................................................64
Warto przeczyta .............................................................................................................................................64
5.
Przetwarzanie wspbiene....................................................................................65
Problemy przetwarzania wspbienego ..........................................................................................................66
Konteksty przetwarzania..................................................................................................................................67
Izolacja i niezmienno....................................................................................................................................68
Optymistyczne i pesymistyczne sterowanie wspbienoci..........................................................................68
Zapobieganie niespjnym odczytom..........................................................................................................69
Zakleszczenia.............................................................................................................................................70
Transakcje........................................................................................................................................................71
ACID .........................................................................................................................................................72
Zasoby transakcyjne ..................................................................................................................................72
Zwikszanie ywotnoci przez ograniczanie izolacji.................................................................................73
Transakcje biznesowe i systemowe ...........................................................................................................74
Wzorce sterowania wspbienoci w trybie offline ......................................................................................76
Serwery aplikacji .............................................................................................................................................77
Warto przeczyta .............................................................................................................................................78
6.
Stan sesji ................................................................................................................79
Zalety sesji bezstanowej...................................................................................................................................79
Stan sesji ..........................................................................................................................................................80
Metody przechowywania danych stanu sesji .............................................................................................81
7.
Obiekty rozproszone ..............................................................................................85
Zwodnicze obiekty rozproszone ......................................................................................................................85
Interfejsy lokalne i interfejsy zdalne ................................................................................................................86
Kiedy stosowa architektur rozproszon........................................................................................................87
Granice dystrybucji ..........................................................................................................................................88
Interfejsy dystrybucji .......................................................................................................................................89
SPIS TRECI
8.
Podsumowanie .......................................................................................................91
Warstwa dziedziny, czyli pocztek ..................................................................................................................92
Warstwa rda danych, czyli krok drugi.........................................................................................................93
rdo danych dla schematu Transaction Script (110) ..............................................................................93
rdo danych dla schematu Table Module (125) .....................................................................................93
rdo danych dla schematu Domain Model (116)....................................................................................94
Warstwa prezentacji.........................................................................................................................................94
Wzorce a technologia.......................................................................................................................................95
Java i J2EE.................................................................................................................................................95
.NET ..........................................................................................................................................................96
Procedury przechowywane ........................................................................................................................97
Usugi WWW ............................................................................................................................................97
Inne systemy warstw aplikacji .........................................................................................................................98
Cz II Wzorce
101
9.
Wzorce logiki dziedziny ......................................................................................103
Transaction Script (Skrypt transakcji)............................................................................................................103
Na czym polega .......................................................................................................................................103
Kiedy uywamy .......................................................................................................................................105
Problem obliczania przychodu.................................................................................................................105
Domain Model (Model dziedziny).................................................................................................................109
Na czym polega .......................................................................................................................................109
Kiedy uywamy .......................................................................................................................................111
Warto przeczyta .....................................................................................................................................112
Przykad: uznanie przychodu (Java) ........................................................................................................112
Table Module (Modu tabeli) .........................................................................................................................117
Na czym polega .......................................................................................................................................118
Kiedy uywamy .......................................................................................................................................120
Przykad: uznanie przychodu (C#)...........................................................................................................120
Service Layer (Warstwa usug) ......................................................................................................................124
Na czym polega .......................................................................................................................................125
Kiedy uywamy .......................................................................................................................................127
Warto przeczyta .....................................................................................................................................127
Przykad: uznanie przychodu (Java) ........................................................................................................127
10.
Wzorce architektury rda danych .....................................................................133
Table Data Gateway (Brama danych tabeli) ..................................................................................................133
Na czym polega........................................................................................................................................133
Kiedy uywamy .......................................................................................................................................134
Warto przeczyta .....................................................................................................................................135
Przykad: brama tabeli osb (C#) ............................................................................................................135
Przykad: brama oparta na zbiorach danych ADO.NET (C#) ..................................................................137
SPIS TRECI
Row Data Gateway (Brama danych wiersza).................................................................................................140

Na czym polega .......................................................................................................................................140
Kiedy uywamy .......................................................................................................................................142
Przykad: brama rekordu osoby (Java).....................................................................................................142
Przykad: uchwyt danych dla obiektu dziedziny (Java) ...........................................................................146
Active Record (Rekord aktywny) ..................................................................................................................147
Na czym polega .......................................................................................................................................147
Kiedy uywamy .......................................................................................................................................148
Przykad: prosta tabela osb (Java)..........................................................................................................148
Data Mapper (Odwzorowanie danych) ..........................................................................................................152
Na czym polega .......................................................................................................................................152
Kiedy uywamy .......................................................................................................................................156
Przykad: proste odwzorowanie obiektowo-relacyjne (Java) ...................................................................157
Przykad: wyczanie metod wyszukujcych (Java) ................................................................................162
Przykad: tworzenie obiektu pustego (Java).............................................................................................165
11.
Wzorce zachowa dla mapowania obiektowo-relacyjnego.................................169
Unit of Work (Jednostka pracy) .....................................................................................................................169
Na czym polega .......................................................................................................................................170
Kiedy uywamy .......................................................................................................................................173
Przykad: rejestracja przez obiekt (Java)..................................................................................................174
Identity Map (Mapa tosamoci)....................................................................................................................178
Na czym polega .......................................................................................................................................178
Kiedy uywamy .......................................................................................................................................180
Przykad: metody mapy tosamoci (Java) ..............................................................................................181
Lazy Load (Opnione adowanie) ................................................................................................................182
Na czym polega .......................................................................................................................................182
Kiedy uywamy .......................................................................................................................................184
Przykad: opniona inicjalizacja (Java)..................................................................................................185
Przykad: wirtualny porednik (Java).......................................................................................................185
Przykad: uchwyt wartoci (Java) ............................................................................................................187
Przykad: widmo (C#)..............................................................................................................................188
12.
Wzorce struktury dla mapowania obiektowo-relacyjnego ..................................197
Identity Field (Pole tosamoci).....................................................................................................................197
Na czym polega .......................................................................................................................................197
Kiedy uywamy .......................................................................................................................................201
Warto przeczyta .....................................................................................................................................201
Przykad: liczba cakowita jako klucz (C#)..............................................................................................201
Przykad: tabela kluczy (Java) .................................................................................................................203
Przykad: klucz zoony (Java) ................................................................................................................205
Foreign Key Mapping (Odwzorowanie do klucza obcego)............................................................................216
Na czym polega .......................................................................................................................................216
Kiedy uywamy .......................................................................................................................................218
Przykad: odwoanie jednowartociowe (Java) ........................................................................................219
Przykad: wyszukiwanie w wielu tabelach (Java) ....................................................................................222
Przykad: kolekcja odwoa (C#).............................................................................................................223
SPIS TRECI
Association Table Mapping (Odwzorowanie do tabeli asocjacji) ..................................................................226

Na czym polega .......................................................................................................................................226
Kiedy uywamy .......................................................................................................................................227
Przykad: pracownicy i umiejtnoci (C#)...............................................................................................227
Przykad: odwzorowanie z kodem SQL (Java) ........................................................................................230
Przykad: jedno zapytanie do obsugi wielu pracownikw (Java)............................................................234
Dependent Mapping (Odwzorowanie skadowych) .......................................................................................239
Na czym polega .......................................................................................................................................239
Kiedy uywamy .......................................................................................................................................240
Przykad: albumy i cieki (Java) ............................................................................................................241
Embedded Value (Warto osadzona) ...........................................................................................................244
Na czym polega .......................................................................................................................................244
Kiedy uywamy .......................................................................................................................................244
Warto przeczyta .....................................................................................................................................245
Przykad: prosty obiekt wartoci (Java) ...................................................................................................245
Serialized LOB (Duy obiekt serializowany).................................................................................................247
Na czym polega .......................................................................................................................................247
Kiedy uywamy .......................................................................................................................................248
Przykad: serializowanie hierarchii dziaw firmy do postaci XML (Java) .............................................249
Single Table Inheritance (Odwzorowanie dziedziczenia do pojedynczej tabeli) ...........................................252
Na czym polega .......................................................................................................................................252
Kiedy uywamy .......................................................................................................................................253
Przykad: tabela zawodnikw (C#) ..........................................................................................................253
Class Table Inheritance (Odwzorowanie dziedziczenia do tabel klas)...........................................................259
Na czym polega .......................................................................................................................................259
Kiedy uywamy .......................................................................................................................................260
Warto przeczyta .....................................................................................................................................260
Przykad: zawodnicy (C#)........................................................................................................................260
Concrete Table Inheritance (Odwzorowanie dziedziczenia do tabel konkretnych)........................................266
Na czym polega .......................................................................................................................................266
Kiedy uywamy .......................................................................................................................................268
Przykad: zawodnicy (C#)........................................................................................................................268
Inheritance Mappers (Klasy odwzorowania dziedziczenia) ...........................................................................274
Na czym polega .......................................................................................................................................275
Kiedy uywamy .......................................................................................................................................276
13.
Wzorce odwzorowa obiektw i relacyjnych metadanych .................................277
Metadata Mapping (Odwzorowanie metadanych) .........................................................................................277
Na czym polega .......................................................................................................................................277
Kiedy uywamy .......................................................................................................................................279
Przykad: uycie metadanych i odzwierciedlania (Java)..........................................................................280
Query Object (Obiekt zapytania) ...................................................................................................................287
Na czym polega .......................................................................................................................................287
Kiedy uywamy .......................................................................................................................................288
Warto przeczyta .....................................................................................................................................289
Przykad: prosty wzorzec Obiekt zapytania (Java) ..................................................................................289
Repository (Magazyn)....................................................................................................................................293
Na czym polega .......................................................................................................................................294
Kiedy uywamy .......................................................................................................................................295
Warto przeczyta .....................................................................................................................................296
Przykad: odnajdywanie osb utrzymywanych przez podan osob (Java) .............................................296
Przykad: zamiana strategii wzorca Repository (Java).............................................................................297
10
SPIS TRECI
14.
Wzorce prezentacji internetowych.......................................................................299
Model View Controller (Model kontrolera widoku) ......................................................................................299
Na czym polega .......................................................................................................................................299
Kiedy uywamy .......................................................................................................................................301
Page Controller (Kontroler strony) ................................................................................................................302
Na czym polega .......................................................................................................................................302
Kiedy uywamy .......................................................................................................................................303
Przykad: prosta prezentacja z serwletem penicym funkcj kontrolera
oraz stron JSP penic rol widoku (Java) ........................................................................................304
Przykad: zastosowanie strony JSP do obsugi dania (Java).................................................................306
Przykad: mechanizm obsugi stron wykorzystujcy kod schowany (C#) ............................................309
Front Controller (Kontroler fasady) ...............................................................................................................313
Na czym polega .......................................................................................................................................313
Kiedy uywamy .......................................................................................................................................315
Warto przeczyta .....................................................................................................................................315
Przykad: prosta prezentacja (Java)..........................................................................................................315
Template View (Szablon widoku)..................................................................................................................318
Na czym polega .......................................................................................................................................318
Kiedy uywamy .......................................................................................................................................322
Przykad: wykorzystanie JSP jako widoku wraz z osobnym kontrolerem (Java) .....................................322
Przykad: strona ASP.NET (C#) ..............................................................................................................325
Transform View (Widok przeksztacajcy)....................................................................................................328
Na czym polega .......................................................................................................................................328
Kiedy uywamy .......................................................................................................................................329
Przykad: proste przeksztacenie (Java) ...................................................................................................330
Two Step View (Widok dwuetapowy)...........................................................................................................332
Na czym polega .......................................................................................................................................332
Kiedy uywamy .......................................................................................................................................333
Przykad: dwuetapowe przeksztacenie XSLT (XSLT) ...........................................................................338
Przykad: JSP i znaczniki niestandardowe (Java) ....................................................................................340
Application Controller (Kontroler aplikacji)..................................................................................................345
Na czym polega .......................................................................................................................................345
Kiedy uywamy .......................................................................................................................................347
Warto przeczyta .....................................................................................................................................347
Przykad: kontroler aplikacji obsugujcy model stanu (Java) .................................................................347
15.
Wzorce dystrybucji ..............................................................................................353
Remote Facade (Zdalna fasada) .....................................................................................................................353
Na czym polega .......................................................................................................................................354
Kiedy uywamy .......................................................................................................................................357
Przykad: zastosowanie komponentu session bean i zdalnej fasady (Java)..............................................357
Przykad: usuga WWW (C#) ..................................................................................................................360
Data Transfer Object (Obiekt transferu danych) ............................................................................................366
Na czym polega .......................................................................................................................................366
Kiedy uywamy .......................................................................................................................................370
Warto przeczyta .....................................................................................................................................371
Przykad: przekazywanie informacji o albumach (Java)..........................................................................371
Przykad: serializacja danych do postaci XML (Java) .............................................................................375
SPIS TRECI
11
16.
Wzorce wspbienoci autonomicznej...............................................................379
Optimistic Offline Lock (Optymistyczna blokada autonomiczna) .................................................................379
Na czym polega .......................................................................................................................................380
Kiedy uywamy .......................................................................................................................................383
Przykad: warstwa dziedziny i wzorzec Data Mappers (165) (Java).............................................................384
Pessimistic Offline Lock (Pesymistyczna blokada autonomiczna) ................................................................389
Na czym polega .......................................................................................................................................390
Kiedy uywamy .......................................................................................................................................393
Przykad: prosty meneder blokad (Java) ................................................................................................394
Coarse-Grained Lock (Blokada gruboziarnista).............................................................................................400
Na czym polega .......................................................................................................................................400
Kiedy uywamy .......................................................................................................................................402
Przykad: wsplna blokada Optimistic Offline Lock (416) (Java)...........................................................403
Przykad: wsplna blokada Pessimistic Offline Lock (426) (Java)..........................................................408
Przykad: blokowanie korzenia przy uyciu blokady Pessimistic Offline Lock (416) (Java) ...................409
Implicit Lock (Blokada domylna) ................................................................................................................410
Na czym polega .......................................................................................................................................411
Kiedy uywamy .......................................................................................................................................412
Przykad: niejawna blokada Pessimistic Offline Lock (426) (Java).........................................................412
17.
Wzorce stanu sesji................................................................................................415
Client Session State (Stan sesji klienta) .........................................................................................................415
Na czym polega .......................................................................................................................................415
Kiedy uywamy .......................................................................................................................................416
Server Session State (Stan sesji serwera) .......................................................................................................418
Na czym polega .......................................................................................................................................418
Kiedy uywamy .......................................................................................................................................420
Database Session State (Stan sesji bazy danych) ...........................................................................................421
Na czym polega .......................................................................................................................................421
Kiedy uywamy .......................................................................................................................................423
18.
Wzorce podstawowe ............................................................................................425
Gateway (Brama) ...........................................................................................................................................425
Na czym polega .......................................................................................................................................426
Kiedy uywamy .......................................................................................................................................426
Przykad: brama poredniczca w korzystaniu z usugi rozsyania komunikatw (Java).........................427
Mapper (Odwzorowanie) ...............................................................................................................................432
Na czym polega .......................................................................................................................................432
Kiedy uywamy........................................................................................................................................433
Layer Supertype (Typ bazowy warstwy) .......................................................................................................434
Na czym polega .......................................................................................................................................434
Kiedy uywamy .......................................................................................................................................434
Przykad: obiekt domeny (Java)...............................................................................................................434
Separated Interface (Interfejs oddzielony) .....................................................................................................435
Na czym polega .......................................................................................................................................435
Kiedy uywamy .......................................................................................................................................437
12
SPIS TRECI
Registry (Rejestr) ...........................................................................................................................................438

Na czym polega .......................................................................................................................................438
Kiedy uywamy .......................................................................................................................................440
Przykad: rejestr bazujcy na wzorcu Singleton (Java)............................................................................440
Przykad: rejestr nadajcy si do zastosowania w rodowiskach wielowtkowych (Java).......................442
Value Object (Obiekt wartoci)......................................................................................................................444
Na czym polega .......................................................................................................................................444
Kiedy uywamy .......................................................................................................................................445
Money (Pienidze) .........................................................................................................................................446
Na czym polega .......................................................................................................................................446
Kiedy uywamy .......................................................................................................................................448
Przykad: klasa Money (Java) ..................................................................................................................449
Special Case (Przypadek szczeglny) ............................................................................................................453
Na czym polega .......................................................................................................................................453
Kiedy uywamy .......................................................................................................................................454
Warto przeczyta .....................................................................................................................................454
Przykad: prosta implementacja pustego obiektu (C#).............................................................................454
Plugin.............................................................................................................................................................456
Na czym polega .......................................................................................................................................456
Kiedy uywamy .......................................................................................................................................457
Przykad: generator identyfikatorw (Java) .............................................................................................457
Service Stub (Usuga zastpcza) ....................................................................................................................461
Na czym polega .......................................................................................................................................461
Kiedy uywamy .......................................................................................................................................462
Przykad: usuga podatkowa (Java)..........................................................................................................462
Record set (Zbir rekordw)..........................................................................................................................465
Na czym polega .......................................................................................................................................465
Kiedy uywamy .......................................................................................................................................467
Dodatki
469
Bibliografia ..........................................................................................................471
Skorowidz ............................................................................................................477
Wzorce logiki dziedziny
Transaction Script (Skrypt transakcji)

Porzdkuje logik dziedziny w procedury, gdzie kada procedura
obsuguje pojedyncze danie warstwy prezentacji.
Prac wikszoci aplikacji biznesowych mona rozpatrywa jako przetwarzanie sekwencji transakcji. Transakcja moe polega na przegldaniu danych w pewien okrelony sposb lub wprowadzaniu w nich zmian. Kada interakcja midzy systemem klienckim a systemem serwera obejmuje
pewn cz logiki aplikacji. W pewnych przypadkach interakcja moe by tak prosta jak wywietlanie przechowywanych w bazie danych. W innym moe wymaga wielu operacji sprawdzania poprawnoci i oblicze.
Wzorzec Transaction Script porzdkuje logik takiej interakcji jako, oglnie rzecz biorc,
pojedyncz procedur, ktra wywouje baz danych bezporednio lub za porednictwem prostego
kodu osaniajcego. Kada transakcja ma wasny skrypt. Dodatkow optymalizacj moe by czenie wsplnych fragmentw kodu w podprocedury.
Na czym polega
Gdy stosujemy wzorzec Transaction Script, logika domeny porzdkowana jest zasadniczo wedug
wykonywanych w systemie transakcji. Gdy celem transakcji jest wprowadzenie rezerwacji pokoju
hotelowego, kod pojedynczej procedury Zarezerwuj Pokj obejmuje sprawdzenie dostpnoci pokoi, okrelenie wysokoci opaty i zaktualizowanie bazy danych.
104
9. WZORCE LOGIKI DZIEDZINY
W prostych przypadkach sposb porzdkowania skryptw transakcji jest naturalny. Oczywicie, podobnie jak w kadym programie, powinnimy wprowadzi przejrzyst struktur moduw.
O ile transakcja nie jest szczeglnie skomplikowana, jest to bardzo proste. Jedn z zalet skryptw
transakcji jest to, e nie ma dla nich znaczenia, jakie operacje wykonuj inne transakcje. Zadaniem
implementowanego kodu jest przyjcie danych wejciowych, odczytanie danych z bazy, przeksztacenie ich, a nastpnie zapisanie wynikw w bazie.
O tym, gdzie umiecimy skrypt transakcji, decyduje przyjty system warstw aplikacji. Lokalizacj tak moe by strona serwera, skrypt CGI lub rozproszony obiekt sesji. Dobrze jest rozdziela skrypty tak dalece, jak to moliwe. Absolutnym minimum s osobne procedury. Jeszcze
lepsze s klasy, oddzielone rwnie od kodu prezentacji i rda danych. Dodatkowo, w skryptach
transakcji nie wprowadzamy adnych wywoa logiki prezentacji. Uatwia to ich modyfikowanie
i testowanie.
Skrypty transakcji mona porzdkowa w klasy dwoma sposobami. Najbardziej typowym
podejciem jest czenie w jednej klasie grupy skryptw. Kada klasa odpowiada wtedy pewnemu
zakresowi tematycznemu. Ukad taki jest przejrzysty i sprawdza si w praktyce. Inn moliwoci
jest umieszczanie kadego skryptu w osobnej klasie (patrz rysunek 9.1). Odpowiada to wzorcowi
Command Gang of Four. Definiujemy wtedy rwnie supertyp takich polece, ktry okrela pewn metod uruchamiania skryptw. Pozwala to operowa skryptami jako obiektami. Trzeba przyzna, e potrzeba taka pojawia si stosunkowo rzadko, ze wzgldu na prostot systemw, gdzie
stosuje si wzorzec Transaction Script. Oczywicie, wiele jzykw pozwala zapomnie o klasach
i definiowa funkcje globalne. Nie mona jednak zapomina, e tworzenie egzemplarzy obiektw
pomaga izolowa dane rnych wtkw przetwarzania.
RYSUNEK 9.1. Skrypty transakcji jako polecenia
Termin skrypt transakcji jest o tyle uzasadniony, e w wikszoci przypadkw kady z nich
odpowiada pojedynczej transakcji bazy danych. Nie jest to regua obowizujca we wszystkich
przypadkach, ale jest stosunkowo dobrym przyblieniem.
TRANSACTION SCRIPT (SKRYPT TRANSAKCJI)
105
Kiedy uywamy
Wielk zalet skryptw transakcji jest ich prostota. Porzdkowanie logiki przy ich uyciu jest bardzo naturalne, gdy caa aplikacja zawiera niewiele kodu. Nie wprowadzamy dodatkowych poziomw zoonoci ani elementw obniajcych wydajno.
Gdy logika biznesowa staje si bardziej skomplikowana, utrzymanie porzdku w skryptach
transakcji staje si coraz bardziej skomplikowane. Podstawowym problemem s powtrzenia kodu. Poniewa kady skrypt ma obsuy dokadnie jedn transakcj, powtrne wprowadzanie takich samych lub podobnych fragmentw jest nieuniknione.
Uwany programista uniknie wikszoci takich problemw, jednak wiksze aplikacje wymagaj zbudowania modelu dziedziny. Wzorzec Domain Model (109) zapewnia znacznie wicej opcji
strukturalizowania kodu, wiksz przejrzysto i ograniczenie problemu powtrze.
Trudno okreli poziom zoonoci, na ktrym skrypty transakcji nie mog by zastosowane.
Bdzie to jeszcze trudniejsze, jeeli przyzwyczailimy si do jednego z wzorcw. Mona oczywicie
przeksztaci skrypty transakcji w model dziedziny, ale nie jest to zmiana prosta, wic dobrze byoby zastanowi si nad waciwym podejciem ju na samym pocztku.
Bez wzgldu na to, jak bardzo lubimy podejcie obiektowe, nie powinnimy skrela wzorca
Transaction Script. Jest wiele prostych problemw i stosowanie dla nich prostych rozwiza pozwala szybciej zakoczy prac.
Problem obliczania przychodu

Do zilustrowania tego i dalszych wzorcw logiki dziedziny bd uywa tego samego problemu.
Poniej przedstawiam jego opis, ktrego ju przy kolejnych wzorcach nie bd niepotrzebnie
powtarza.
Obliczanie uznania przychodu (ang. revenue recognition) to do typowe dla systemw biznesowych zagadnienie. Podstawowym problemem jest to, kiedy mona zaksigowa otrzymany
przychd (ang. revenue). Gdy sprzedaj filiank kawy, sytuacja jest prosta: wydaj kaw, bior
pienidze i natychmiast wprowadzam odpowiedni kwot do ksiki przychodw. Nie zawsze
jednak jest tak atwo. Wyobramy sobie, e dostaj zaliczk na ten rok. Nawet jeeli jest to niewielka kwota, jej natychmiastowe wprowadzenie do ksiki moe nie by moliwe, poniewa
usuga bdzie wykonana dopiero na przestrzeni tego roku. Jedn z moliwoci moe by wprowadzanie jednej dwunastej tej kwoty w kadym kolejnym miesicu, na wypadek, gdyby umowa zostaa nagle rozwizana.
Jest wiele rnych i czsto zmiennych regu obliczania przychodu na potrzeby urzdu skarbowego. Cz ustala ustawa, inne wynikaj ze standardw ksigowoci, jeszcze inne z wewntrznych zasad firmy. ledzenie przychodu moe by bardzo zoonym zagadnieniem.
Nie bdziemy si tutaj wgbia w szczegy tego procesu. Wyobramy sobie jedynie firm, ktra sprzedaje trzy rodzaje towarw: edytory tekstu, bazy danych i arkusze kalkulacyjne.
Zgodnie z przyjtymi zasadami, cao przychodu z umowy sprzeday (ang. contract) edytora
tekstu moe zosta zaksigowana od razu. W przypadku arkusza kalkulacyjnego, jedn trzeci
przychodu wprowadzamy od razu, jedn trzeci po szedziesiciu dniach i pozosta jedn
trzeci po dziewidziesiciu dniach. Gdy sprzedajemy baz danych, jedn trzeci wprowadzamy
od razu, jedn trzeci po trzydziestu dniach i jedn trzeci po szedziesiciu dniach. Oczywicie zasady te niewiele maj wsplnego z rzeczywistoci i maj suy jedynie zilustrowaniu omawianych zagadnie.
106
RYSUNEK 9.2. Uproszczony model obliczania przychodu. Kada umowa obejmuje wiele wartoci
przychodu, powizanych z okreleniem, kiedy rne czci przychodu trafiaj do ksig
Przykad: uznanie przychodu (Java)

W niniejszym przykadzie stosujemy dwa skrypty transakcji: jeden do obliczania uzna przychodu
dla danej umowy i drugi do okrelenia, jaka kwota przychodu z danej umowy zostaa uznana do
okrelonego dnia. Baza danych ma trzy tabele: towarw (ang. products), umw (ang. contracts) i uzna
przychodu (ang. revenue recognitions).

!

!

!"#
$%&'&

!"#
Pierwszy skrypt oblicza kwot uznania na dany dzie. Mona j wyliczy w dwch krokach: w pierwszym wybieramy wiersze tabeli uzna przychodu, w drugim sumujemy kwoty.
Projekty oparte na wzorcu Transaction Script korzystaj czsto ze skryptw, ktre operuj
bezporednio na bazie danych, wykorzystujc kod SQL. W tym przykadzie korzystamy z prostej
bramy Table Data Gateway (133) jako osony zapyta SQL. Ze wzgldu na prostot przykadu,
uyjemy tylko jednej, wsplnej bramy, nie tworzc osobnych dla kadej tabeli. Definiujemy w jej
obrbie odpowiedni metod wyszukiwania, (!)
.
*+,,,
- (!)
!
%((

+ ./ 0
$

1-,

(! 2
,!3
2
,4(, 52

1,/ .
2

2
6

(
!(! 1
7 78
7)#%
!78
79:
1;<
!"#=1;72

-2
TRANSACTION SCRIPT (SKRYPT TRANSAKCJI)
107
Drugi skrypt suy do podsumowania danych przekazanych przez bram.

!
,,,
-%
!" !
< -
%((0
%
1%,
>2

0

1-,(!)

< -
(2
+
,/0

1
,%,

,!!7 72
6

2
6 ./ 0
++ / 2
6
6
W przypadku tak prostych oblicze, procedura w jzyku Java mogaby rwnie zosta zastpiona
wywoaniem SQL, ktre sumuje wartoci przy uyciu funkcji agregujcej.
Podobny podzia stosujemy przy obliczaniu uzna przychodu dla wybranej umowy. Skrypt
warstwy dziedziny realizuje logik biznesow.
!
,,,
- !!
< -
0

0

1-,(

< -
2

,/2
% 1%,

,!!7
72
%(
!1+%(
,!7 !72

! 1
,!
!7 72
( ,5 7 70
%?@1 ,A2
-,
!

< -
?>@
!2
-,
!

< -
?3@
!,B>2
-,
!

< -
?4@
!,C>2
6( ,5 7970
-,
!
< -

!2
6( ,5 770
%?@1 ,A2
-,
!

< -
?>@
!2
-,
!

< -
?3@
!,A>2
-,
!

< -
?4@
!,B>2
6
6 ./ 0
++ / 2
6
6
108
Zwrmy uwag na uycie klasy Money (446) do alokacji. Zapobiega ona gubieniu pojedynczych
groszy (lub centw), o co atwo przy dzieleniu kwot pieninych przez trzy.
Obsuga SQL jest zrealizowana w formie wzorca Table Data Gateway (133). Pierwsza procedura
znajduje umow.
*+,,,
- (
!

+ ./ 0
$

1-,

(
2
,!3
2

1,/ .
2

2
6

(
!(
1
7 D78
7)#%

78
79:1;<,
1 ,72
Druga procedura to osona instrukcji < .

*+,,,
-
!!
% %((

+ ./ 0
$

1-,

! 2
,!3
2
,!4 , 2
,A(, 52
,/ E 2
6

(
!
! 1
7< <#
!FE ;;;72
Gdy uywamy jzyka Java, usuga obliczania uzna dochodu moe mie posta tradycyjnej klasy
lub obiektu bean sesji.
Czytelnik, ktry nie jest przyzwyczajony do modelowania dziedziny, uzna prawdopodobnie
przedstawion tu implementacj za znacznie prostsz ni przedstawiona w opisie wzorca Domain
Model (109). Niestety, nieco trudniej w zwizy sposb przedstawi (lub wyobrazi sobie), co stanie si, gdy reguy biznesowe bd bardziej skomplikowane. Stosowane w praktyce reguy obliczania uzna przychodu nie s proste, a rnice midzy nimi wyznacza nie tylko produkt, ktrego
dotycz, ale i data operacji (jeeli umowa zostaa podpisana przed 15 kwietnia, obowizuje taka
a taka regua). Gdy poziom zoonoci jest duy, utrzymanie spjnej konstrukcji skryptw transakcji jest bardzo trudne, co doskonale uzasadnia przywizanie mionikw podejcia obiektowego
do stosowania modeli dziedziny.
DOMAIN MODEL (MODEL DZIEDZINY)
109
Domain Model (model dziedziny)

Obiektowy model dziedziny, obejmujcy wymagane zachowania i dane.
Logika biznesowa moe osign bardzo duy poziom zoonoci. Reguy i logika opisuj wiele
rnych przypadkw i wariantw zachowa, a wanie rozwizanie problemu zoonoci byo
gwn przesank stworzenia koncepcji obiektw. Model dziedziny to sie takich poczonych ze
sob obiektw, gdzie kady obiekt reprezentuje pewien znaczcy element lub czynnik. Elementy
te mog by tak znaczne jak przedsibiorstwo lub tak niewielkie jak pojedynczy wiersz formularza
zamwienia.
Na czym polega
Wprowadzenie w aplikacji wzorca Domain Model (109) wymaga stworzenia do rozbudowanej
koncepcyjnie warstwy obiektw, ktre modeluj rozwizywany problem. Nale do nich obiekty
reprezentujce dane przedsibiorstwa i obiekty odpowiadajce reguom jego pracy. Dane i procesy
najczciej czy si ze sob, aby skupi czynnoci przetwarzania i informacje, ktrymi operuj.
Obiektowy model dziedziny moe przypomina model bazy danych, zawsze jednak dziel je
istotne rnice. Model dziedziny czy dane i procesy, ma wielowartociowe atrybuty, zoon
sie asocjacji i wykorzystuje dziedziczenie.
Mona wyrni dwa rodzaje modeli dziedziny. Prosty model przypomina projekt bazy danych i dominuje w nim ukad jeden obiekt modelu-jedna tabela bazy danych. Rozbudowany
model dziedziny znacznie odbiega od struktury bazy i wykorzystuje dziedziczenie, strategie i inne
wzorce Gang of Four, jak rwnie zoone sieci niewielkich, poczonych ze sob obiektw. Takie
110
podejcie jest lepsze, gdy logika jest bardziej skomplikowana, trudniej jednak wwczas przeprowadzi mapowanie do bazy. W prostym modelu mona korzysta z aktywnych rekordw (Active
Record (147)), rozbudowany wymaga mechanizmu Data Mapper (152).
Poniewa funkcje biznesowe wymagaj zawsze wielu pniejszych zmian, wana jest moliwo atwego modyfikowania, kompilowania i testowania warstwy, w ktrej s implementowane.
Musimy wic dba o to, aby sprze midzy modelem a innymi warstwami systemu byo jak
najmniej. atwo zauway, e podstaw wielu wzorcw ukadu warstwowego jest wanie utrzymanie jak najmniejszej zalenoci midzy warstw dziedziny a innymi.
Rozwizania obsugi modelu dziedziny mog by rne. Najprostszym przypadkiem jest
aplikacja dla jednego uytkownika, gdzie cay graf obiektw zostaje odczytany z pliku i zaadowany do pamici. O ile sprawdza si to w przypadku aplikacji biurowych, nie jest raczej stosowane w wielowarstwowych aplikacjach systemw informacyjnych z tej prostej przyczyny, e obiektw
jest wtedy zbyt wiele. Pami jest zbyt maa, aby takie obcienie byo uzasadnione, a samo adowanie obiektw trwa zbyt dugo. Urok obiektowych baz danych polega wanie na tym, e zapewniaj
iluzj wykonywania takiej operacji, podczas gdy w rzeczywistoci jedynie zarzdzaj przenoszeniem
obiektw pomidzy pamici a dyskiem.
Brak obiektowej bazy danych zmusza do samodzielnego projektowania podobnych rozwiza.
W typowym przypadku w kadej sesji adowany jest graf obiektw, ktrych ta sesja wymaga. Nie
s to jednak nigdy wszystkie obiekty aplikacji i zazwyczaj nie wszystkie stosowane klasy. Przykadowo, gdy przegldany jest zbir umw, z dysku adowane s tylko obiekty odpowiadajce produktom, do ktrych te umowy si odwouj. Gdy przeprowadzane s obliczenia operujce umowami
i uznaniami przychodu, obiekty reprezentujce produkty mog nie by adowane w ogle. O tym,
co zostanie zaadowane do pamici, decyduj obiekty zarzdzajce mapowaniem do bazy danych.
Gdy pojawia si potrzeba utrzymania tego samego grafu obiektw pomidzy kolejnymi wywoaniami serwera, niezbdne jest zachowanie danych stanu. To zagadnienie omawiamy w rozdziale powiconym stanowi sesji (strona 79).
Typowym problemem zwizanym z logik dziedziny jest nadmierne puchnicie obiektw.
W trakcie projektowania ekranu do zarzdzania zamwieniami moemy zauway, e niektre
funkcje zamwie su wycznie do jego obsugi. Przypisanie tych funkcji zamwieniu moe
doprowadzi do niepotrzebnej rozbudowy odpowiedniej klasy. Niepotrzebnej, poniewa wiele
funkcji wykorzystanych zostaje tylko w jednym przypadku uycia. Wielu programistw zwraca
wic pilnie uwag na to, czy pewne funkcje maj charakter oglny (i mog by implementowane
w klasie Zamwienie), czy s specyficzne dla okrelonych operacji. W tym ostatnim przypadku powinny by implementowane w pewnej klasie zwizanej z zastosowaniem obiektu. Moe to oznacza
skrypt transakcji lub warstw prezentacji.
Problem oddzielania zachowa specyficznych dla zastosowa obiektu jest powizany z zagadnieniem duplikacji kodu. Funkcj oddzielon od zamwienia trudniej znale, atwo wic na
pewnym etapie projektu o przeoczenie prowadzce do ponownej implementacji tego samego
zachowania. Powtrzenia kodu z kolei prowadz do szybkiego zwikszania jego zoonoci i utraty
spjnoci. Z moich dowiadcze wynika, e puchnicie obiektw nie jest tak czstym zjawiskiem, jak mogoby si na pierwszy rzut oka wydawa. Cho nie mona zaprzeczy jego wystpowaniu, atwo je wykry i wprowadzi niezbdne korekty. Zalecabym wic raczej powstrzymanie
si od oddzielania funkcji od obiektw i implementowanie ich w tych klasach, gdzie w naturalny
sposb pasuj. Odchudzanie obiektw stosujemy dopiero wtedy, gdy faktycznie stwierdzimy, e
jest konieczne.
111
Implementacja w jzyku Java

Implementowanie modelu dziedziny w J2EE wzbudza mnstwo emocji. Wiele materiaw szkoleniowych
i podrcznikw zaleca stosowanie do tego celu obiektw entity bean. Podejcie takie wie si jednak
z pewnymi powanymi trudnociami. By moe zostan one usunite w przyszych wersjach specyfikacji (w chwili pisania tej ksiki obowizuje wersja 2.0).
Obiekty entity bean najlepiej sprawdzaj si, gdy stosujemy mechanizm Container Managed Persistance (CMP, kontenerowo zarzdzane skadowanie). Mona wrcz stwierdzi, e w innych rozwizaniach stosowanie obiektw entity bean nie ma uzasadnienia. CMP jest jednak do ograniczon form
mapowania obiektowo-relacyjnego i nie pozwala stosowa wielu wzorcw potrzebnych w rozbudowanych modelach dziedziny.
Obiekty entity bean nie powinny mie charakteru wielobienego, co znaczy, e jeeli obiekt entity
bean wywouje inny obiekt, ten inny obiekt (ani aden inny w acuchu dalszych wywoa) nie moe
wywoa pierwszego obiektu entity bean. Jest to o tyle kopotliwe, e rozbudowane modele dziedziny
czsto wykorzystuj wielobieno. Co gorsza, zachowania tego rodzaju s trudne do wykrycia. Prowadzi to do popularnego zalecenia, aby obiekty entity bean nie wywoyway si wzajemnie. Pozwala to co
prawda unikn wielobienoci, ale znacznie ogranicza korzyci ze stosowania wzorca Domain Model.
Model dziedziny powinien opiera si na obiektach z interfejsami o duej ziarnistoci (podobna cecha
powinna charakteryzowa sam struktur obiektw). Jednak zdalne wywoywanie obiektw z interfejsami o duej ziarnistoci prowadzi do bardzo niskiej wydajnoci systemu. W konsekwencji, pomimo tego,
e obiekty entity bean mog by dostosowane do wywoa zdalnych (we wczeniejszych wersjach specyfikacji bya to wymagana cecha), w modelu dziedziny powinnimy stosowa wycznie interfejsy lokalne.
Aby korzysta z obiektw entity bean, niezbdny jest kontener i poczenie z baz danych. Zwiksza
to czas kompilacji i czas niezbdny do wykonania testw, bo obiekty te musz korzysta z bazy danych.
Rwnie debugowanie obiektw entity bean nie naley do najprostszych.
Alternatyw jest stosowanie zwykych obiektw jzyka Java, nawet jeeli takie podejcie moe by
dla wielu osb zaskakujce zadziwiajce, jak wielu programistw jest utwierdzonych w przekonaniu,
e w kontenerze EJB nie mog pracowa zwyke obiekty. Doszedem kiedy do wniosku, e zwyke
obiekty Java id w zapomnienie, bo nie maj adnej nazwy. Dlatego wanie, przygotowujc si do pewnej
dyskusji w 2000 roku, razem z Rebecc Parsons i Joshem Mackenzie wymylilimy nazw POJO (ang.
plain old Java objects, zwyke obiekty jzyka Java). Model dziedziny oparty na obiektach POJO stosunkowo atwo jest opracowa, szybko si kompiluje, a mona go uruchamia i testowa poza kontenerem EJB.
Jest on zasadniczo niezaleny od EJB (co by moe jest przyczyn, dla ktrej producenci zwizani z EJB
nie zachcaj do takich rozwiza).
Reasumujc, wydaje mi si, e zastosowanie obiektw entity bean do implementacji modelu dziedziny
sprawdza si wtedy, gdy logika dziedziny jest tylko umiarkowanie rozbudowana. Wwczas model moe
mie prosty zwizek z baz danych, oparty na oglnej zasadzie przypisania jednej klasy entity bean do
jednej tabeli bazy danych. Bardziej rozbudowana logika, wykorzystujca dziedziczenie, strategie i inne
wyrafinowane wzorce, wymaga modelu opartego na obiektach POJO i wzorcu Data Mapper (152). Ten
ostatni moemy wygenerowa korzystajc ze specjalnego, zakupionego narzdzia.
Mnie osobicie najbardziej zniechca do korzystania z EJB fakt, e rozbudowany model dziedziny
jest sam w sobie wystarczajco skomplikowany, aby skania do utrzymywania jak najwikszej niezalenoci od rodowiska implementacji. EJB wymusza pewne schematy dziaania, co sprawia, e musimy zajmowa si nie tylko dziedzin, ale i jednoczenie rodowiskiem EJB.
Kiedy uywamy
O ile odpowied na pytanie jak jest trudna ze wzgldu na obszerno tematu, odpowied na pytanie kiedy nie jest atwa ze wzgldu na swoj oglno i prostot. Sprowadza si bowiem do
rozwaenia poziomu zoonoci funkcji systemu. Skomplikowane i zmienne reguy biznesowe,
112
obejmujce sprawdzanie poprawnoci, obliczenia i derywacje, zdecydowanie powinny skania do

zastosowania modelu obiektowego. Z drugiej strony, proste weryfikacje typu not null i obliczanie kilku podsumowa to zadanie idealne dla skryptw transakcji.
Jednym z czynnikw jest dowiadczenie zespou pracujcego nad aplikacj, a konkretniej jak
radzi on sobie z operowaniem obiektami dziedziny. Projektowanie i praca z modelem dziedziny to
co, czego trzeba si nauczy. Std wiele artykuw opisujcych t zmian paradygmatu w rozwizaniach obiektowych. Proces nauki jest dugi, a zdobycie praktyki wymaga czasu. Ukoronowaniem
nauki jest rzeczywista zmiana sposobu mylenia, kiedy projektant przestaje stosowa inne wzorce
warstwy dziedziny i nie chce uywa skryptw transakcji w adnych aplikacjach poza, ewentualnie,
najprostszymi.
Gdy stosujemy model dziedziny, podstawowym schematem interakcji z baz danych jest Data
Mapper (152). Pomaga on utrzyma niezaleno modelu od bazy i jest najlepszym podejciem,
gdy model dziedziny i schemat bazy danych znacznie rni si od siebie.
Uzupenieniem modelu dziedziny moe by warstwa usug (Service Layer (124)), zapewniajca
modelowi przejrzysty interfejs API.
Warto przeczyta
Niemal kada ksika traktujca o projektowaniu obiektowym porusza zagadnienie modeli dziedziny. Decyduje o tym fakt, e w powszechnym rozumieniu programowanie obiektowe opiera si
wanie na takim podejciu.
Czytelnikom poszukujcym wprowadzenia do projektowania obiektowego polecam obecnie
ksik Larman. Przykady modelu dziedziny znajdziemy w Fowler AP. Hay zawiera wiele przykadw ukierunkowanych na kontekst relacyjny. Zbudowanie dobrego modelu dziedziny wymaga dobrej znajomoci teorii projektowania obiektowego. Jest ona doskonale wyoona w Martin and Odell.
Wyczerpujcy przegld wzorcw charakterystycznych dla rozbudowanych modeli dziedziny, a take
innych systemw obiektowych, znajdziemy w Gang of Four.
Eric Evans pisze obecnie ksik Evans, traktujc wanie o budowaniu modeli dziedziny. Do
chwili pisania tych sw miaem okazj zetkn si tylko z jej wstpn wersj, ale wygldaa ona
bardzo obiecujco.

Opisywanie zasad modelowania dziedziny jest do niewdzicznym zajciem, poniewa kady
przykad, ktry mona przedstawi, jest z koniecznoci bardzo uproszczony. Uproszczenia te skutecznie ukrywaj wszelkie mocne strony tego rodzaju rozwiza. Mona je naprawd doceni tylko wtedy, gdy rozpatrzymy naprawd zoon dziedzin, na co oczywicie nie ma tu miejsca.
Cho przykad nie moe by wystarczajco dobrym dowodem wielkich korzyci, jakie zapewnia modelowanie dziedziny, moe przynajmniej da Czytelnikowi pewne pojcie o tym, jak
taki model moe wyglda. Korzystam tutaj z tego samego przykadu (strona 105), ktry posuy
do zilustrowania wzorca Transaction Scripts (skryptw transakcji).
Pierwsz rzecz, ktr zauwaymy, bdzie to, e kada klasa obejmuje zarwno zachowania,
jak i dane (patrz rysunek 9.3). Nawet prosta klasa ! zawiera metod suc do
okrelania, czy w danym dniu warto obiektu zostaa ju zaksigowana.
113
RYSUNEK 9.3. Diagram klas dla przykadu modelu dziedziny

!,,,

% 2

%(2
- !% %(0
, 1 2
,12
6
-%! 0

2
6
!"-%(#(0

#(,(
GG#(,5 2
6
Obliczanie wielkoci przychodu uznanego na dany dzie wymaga klas umowy i uznania przychodu.

,,,

!1+
2
114
-%

!" %(#(0
%
1%,
>2

1
!,

2
+,</0
!
1 !,/2
(
,!"-#(

1
,
,! 2
6

2
6
Charakterystyczny dla modelw dziedziny jest sposb, w jaki wiele klas wsppracuje ze sob
w realizacji nawet najprostszych zada. To wanie prowadzi czsto do konkluzji, e w programach obiektowych ogromn ilo czasu spdzamy na przeszukiwaniu kolejnych klas, szukajc tej,
ktra jest nam w danej chwili potrzebna. Konkluzja taka jest niewtpliwie suszna. Warto takiego rozwizania doceniamy, gdy decyzja o uznaniu przychodu w okrelonym dniu staje si bardziej
skomplikowana. Musimy te rozway informacje dostpne dla innych obiektw. Zamknicie zachowania w obiekcie, ktry potrzebuje okrelonych danych, pozwala unikn powtrze kodu i ogranicza sprzenia midzy obiektami.
Analiza sposobu obliczania wartoci i tworzenia obiektw reprezentujcych uznanie przychodu
pozwala zauway charakterystyczne dla modelu dziedziny liczne obiekty o niewielkich rozmiarach.
W przedstawionym przykadzie, obliczenia i tworzenie obiektu rozpoczynaj si od klienta i s
przekazywane poprzez produkt do hierarchii strategii. Wzorzec strategii Gang of Four to popularny wzorzec projektowania obiektowego, ktry umoliwia poczenie grupy operacji w hierarchi
niewielkich klas. Kady egzemplarz produktu jest poczony z pojedynczym egzemplarzem strategii
obliczania uznania, okrelajcej, ktry algorytm zostanie uyty do obliczenia uznania. W tym
przypadku mamy dwie podklasy strategii obliczania uznania, reprezentujce dwa rne przypadki.
Struktura kodu wyglda nastpujco:

,,,

$

2

%
2

%(+ !2

!2
-
$

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

!2

!
!
!
!2
-$

!!
!
!
!0
,12
,
!
!1
!
!2
6
115
-$
+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
,! ,A2

, !+ !
?>@
,!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 wic utworzenia nowej podklasy, z wasn metod !. Znacznie uatwia to wprowadzanie do systemu nowych
algorytmw.
Gdy tworzymy obiekty reprezentujce produkty, czymy je z odpowiednimi obiektami strategii.
Implementuj to w kodzie testu.

,,,

$
+
1$
,+9
$

7!9
72
116

$
1$
,+
7!72

$
-1$
,+-7!72
Gdy wszystkie elementy s gotowe, obliczanie uznania przychodu nie wymaga znajomoci podklas
strategii.

,,,
- !0

, !2
6
$
,,,
!

0

!
!, !
2
6
Obiektowa zasada przekazywania od obiektu do obiektu przenosi zachowanie do tego z nich,

ktry jest najbardziej uprawniony do obsugi tego zachowania, a co wicej, realizuje wikszo
funkcji warunkowych. Mona zauway, e w obliczeniach nie ma adnych instrukcji warunkowych. Wprowadzony ukad obiektw sprawia, e algorytmy w naturalny sposb podaj waciw
ciek. Modele dziedziny sprawdzaj si bardzo dobrze, gdy w systemie jest wiele podobnych
warunkw, bo wwczas warunki te mog zosta zrealizowane przez sam struktur obiektw.
Przenosi to zoono z algorytmw do samych zwizkw midzy obiektami. Im bardziej podobna
logika, tym czciej okazuje si, e ta sama sie zwizkw jest wykorzystywana przez rne czci
systemu. Kady algorytm zaleny od sposobu obliczania uznania przychodu moe korzysta z wprowadzonego ukadu.
Pragn zwrci uwag Czytelnika na fakt, e w tym przykadzie nie przedstawiam adnego
opisu sposobw pobierania i zapisywania obiektw do bazy danych. Wynika to z kilku przyczyn.
Po pierwsze, mapowanie modelu dziedziny do bazy danych jest do skomplikowane, wic zwyczajnie uciekam przed trudami tego opisu. Po drugie, samym celem wprowadzenia modelu dziedziny jest ukrycie bazy danych, tak przed warstwami wyszymi, jak i przed osobami, ktre pracuj
z modelem. Pominicie opisu interakcji z baz danych jest wic odbiciem tego, jak w rzeczywistoci
wyglda programowanie w rodowisku opartym na wzorcu Domain Model.
TABLE MODULE (MODU TABELI)
117
Table Module (modu tabeli)

Pojedynczy egzemplarz obsuguje logik biznesow
dla wszystkich wierszy tabelilub widoku bazy danych.
Jedn z podstawowych zasad podejcia obiektowego jest wizanie danych z funkcjami (zachowaniami), ktre na tych danych operuj. Tradycyjny schemat opiera si na obiektach o okrelonej
tosamoci. Rozwizania tego rodzaju reprezentuje wzorzec Domain Model (109). Gdy wic mamy
do czynienia z klas Pracownik, kady egzemplarz tej klasy odpowiada pewnemu pracownikowi.
Systemy tego rodzaju sprawdzaj si dobrze w praktyce, poniewa posiadanie odwoania do pracownika umoliwia wykonywanie zwizanych z nim operacji, podanie za odwoaniami i gromadzenie danych o pracowniku.
Jednym z problemw charakterystycznych dla modelu dziedziny jest implementacja interfejsu
relacyjnej bazy danych. Mona powiedzie, e baza relacyjna jest w takich rozwizaniach jak
ciotka-wariatka, zamknita na strychu i wspominana w rozmowach jak najrzadziej i tylko wtedy,
kiedy jest to absolutnie konieczne. Wynikiem tego s niezwyke akrobacje, do ktrych programista
jest zmuszony w sytuacji, kiedy pojawia si potrzeba pobrania lub zapisania danych w bazie. Transformacje pomidzy dwiema reprezentacjami danych okazuj si czasochonnym i wymagajcym
fragmentem pracy nad aplikacj.
Gdy korzystamy ze wzorca Table Module, logika dziedziny zostaje uporzdkowana w klasy,
ktre odpowiadaj poszczeglnym tabelom bazy danych. Pojedynczy egzemplarz takiej klasy zawiera rnorodne procedury operujce danymi tabeli. Gwnym wyrnikiem wzorca Domain
Model (109) jest to, e gdy mamy do czynienia z wieloma zamwieniami, jednemu zamwieniu
odpowiada jeden obiekt zamwienia. Gdy korzystamy ze wzorca Table Module, jeden obiekt obsuguje wszystkie zamwienia.
118
Na czym polega
Zalet wzorca Table Module jest to, e umoliwia poczenie ze sob danych i zachowa bez utraty
wartoci reprezentowanych przez relacyjn baz danych. Z wierzchu modu tabeli wyglda jak
zwyky obiekt. Gwn rnic jest brak powizania go z tosamoci bytw, na ktrych operuje.
Aby uzyska adres pracownika, uywamy metody w rodzaju $
+, -
"
!
$
+. Za kadym razem, gdy zamierzamy wykona operacj na wybranym pracowniku,
musimy przekaza pewnego rodzaju odwoanie do jego tosamoci. Najczciej jest to klucz gwny
tabeli bazy danych.
Wzorzec Table Module stosujemy zazwyczaj z pewn struktur skadowania danych opart
na tabelach. Uoone w tabele dane s najczciej wynikiem wywoania SQL i s przechowywane
w obiekcie Record Set (465), ktrego zachowania s podobne do zachowa tabeli SQL. Zadaniem
moduu tabeli jest zapewnienie interfejsu danych opartego na metodach. Grupowanie zachowa
wedug tabel zapewnia wiele zalet hermetyzacji funkcje pozostaj blisko zwizane z danymi,
na ktrych operuj.
Wykonanie pewnych operacji czsto wymaga uycia funkcji wielu moduw tabel. Niejednokrotnie wic mona si spotka z wieloma moduami, ktre operuj na tym samym obiekcie Record
Set (465) (patrz rysunek 9.4).
RYSUNEK 9.4. Kilka moduw tabeli moe korzysta z tego samego obiektu Record Set (465)
Najbardziej przejrzystym przykadem rozwizania opartego na moduach tabel bdzie sytuacja,

kiedy kady z moduw odpowiada pojedynczej tabeli bazy danych. Jeeli jednak w bazie danych
zdefiniowane zostay pewne uyteczne zapytania i widoki, rwnie i one mog mie wasne moduy.
Modu tabeli moe by egzemplarzem klasy lub grup metod statycznych. Zalet stosowania
egzemplarzy jest to, e mona wwczas inicjalizowa modu tabeli przy uyciu zbioru rekordw
(ktry moe by wynikiem zapytania). Egzemplarz moduu suy w takiej sytuacji do wykonywania
operacji na wierszach zestawu rekordw. Egzemplarze pozwalaj rwnie korzysta z dziedziczenia,
mona wic stworzy modu dla wybranej grupy umw, ktry zawiera zachowania nie majce odniesienia do kadej z nich.
119
Zapytania w module tabeli mog przyj posta metod fabrykujcych (ang. factory methods).
Alternatyw jest wzorzec Table Data Gateway (133), cho wwczas w projekcie pojawia si dodatkowa klasa i zwizany z ni mechanizm. Zalet takiego rozwizania jest moliwo korzystania
z pojedynczego moduu tabeli do obsugi danych z rnych rde, poniewa kade z nich moe
obsugiwa inna brama Table Data Gateway (133).
Gdy uywamy bramy Table Data Gateway (133), aplikacja wykorzystuje j przede wszystkim
do zbudowania obiektu Record Set (465). Obiekt ten staje si wwczas argumentem konstruktora
moduu tabeli. Gdy niezbdne jest wykorzystanie wielu moduw tabeli, mona utworzy je przy
uyciu tego samego zestawu rekordw. Modu tabeli realizuje wwczas operacje logiki biznesowej,
po czym przekazuje zmodyfikowany obiekt Record Set (465) do warstwy prezentacji, ktra wywietla dane zestawu rekordw i umoliwia wprowadzanie zmian. W warstwie prezentacji mona
wwczas stosowa widety dostosowane do operowania danymi tabel. Widety te nie odrniaj
zestaww rekordw pobranych bezporednio z relacyjnej bazy danych od tych, ktre zostay zmodyfikowane przez modu tabeli. Po zmianach, wprowadzonych przy uyciu graficznego interfejsu
uytkownika, dane powracaj do moduu tabeli w celu sprawdzenia poprawnoci, po czym s zapisywane w bazie danych. Jedn z zalet takiego podejcia jest moliwo testowania moduu tabeli
przez stworzenie obiektu Record Set (465) w pamici, bez uycia bazy danych (rysunek 9.5).
RYSUNEK 9.5. Typowe interakcje warstw otaczajcych modu tabeli
Sowo tabela w nazwie wzorca sugeruje powizanie kadego moduu z pojedyncz tabel
bazy danych. Jest to zasadniczo prawd, ale nie obowizujc regu. Mona stosowa moduy tabeli
dla bardziej znaczcych widokw i innych zapyta. Struktura moduu tabeli nie jest cile uwarunkowana struktur tabel bazy. Mona wic korzysta z tabel wirtualnych, ktre powinny by
widoczne dla aplikacji, czyli wanie widokw i zapyta.
120
Kiedy uywamy
Wzorzec Table Module opiera si na danych uporzdkowanych w tabele. Korzystanie z niego jest
uzasadnione, gdy korzystamy z takich danych przy uyciu obiektw Record Set (465). Obiekty
takie staj si osi kodu aplikacji, wic dostp do nich musi by stosunkowo prosty.
Wzorzec Table Module nie zapewnia penego wykorzystania koncepcji programowania obiektowego przy dobrze uporzdkowanej, zoonej logice aplikacji. Nie mona tworzy bezporednich
relacji midzy egzemplarzami obiektw. Polimorfizm rwnie nie sprawdza si w takich rozwizaniach. Gdy poziom zoonoci jest duy, budowanie modelu dziedziny bdzie lepszym podejciem. Wybr pomidzy wzorcami Table Module a Domain Model (109) sprowadza si w zasadzie
do wyboru pomidzy potencjaem obsugi bardzo zoonej logiki a prostot integracji z opartymi
na tabelach strukturami danych.
Jeeli obiekty modelu dziedziny i tabele bazy danych mog opiera si na podobnej organizacji,
warto rozway poczenie wzorca Domain Model (109) z obiektami Active Record (147). Zalety
moduw tabeli przewyszaj korzyci z takiej kombinacji w sytuacji, gdy inne czci aplikacji
korzystaj ze wsplnej, tabelarycznej struktury danych. Std bierze si niewielka popularno
wzorca Table Module (117) w rodowisku Java. I to jednak moe si zmieni wraz z coraz szerszym stosowaniem mechanizmu zestaww wierszy (ang. row set).
Najczciej spotykanym zastosowaniem wzorca Table Module s projekty oparte na mechanizmach Microsoft COM. W rodowisku COM (i .NET) zestaw rekordw (Record Set (465)) jest
podstawowym typem repozytorium danych aplikacji. Zestawy rekordw mog by przekazywane
do interfejsu uytkownika, gdzie specjalne widety wywietlaj zawarte w nich dane. Biblioteki
Microsoft ADO zapewniaj niezbdny mechanizm dostpu do danych struktur relacyjnych. W takim
rodowisku moduy tabeli umoliwiaj efektywne porzdkowanie logiki biznesowej bez utraty
uatwie w obsudze tabel, jakie zapewniaj rne dostpne programicie aplikacji elementy.
Przykad: uznanie przychodu (C#)

Pora powrci do przykadu aplikacji obliczajcej uznania przychodu (opis na stronie 105), ktrej
implementacje suyy nam do zilustrowania wczeniej omawianych wzorcw warstwy dziedziny.
Dla przypomnienia, celem jest tu obliczenie uznania przychodu dla zamwie w sytuacji, gdy reguy obliczania rni si w zalenoci od produktu, ktrego dane uznanie dotyczy. Mamy do
czynienia z trzema produktami: edytorami tekstu, arkuszami kalkulacyjnymi i bazami danych.
System moduw tabeli opiera si na pewnym schemacie danych, ktry zazwyczaj jest modelem relacyjnym (chocia w przyszoci w podobnych schematach spotkamy si zapewne z modelami XML). W tym przypadku podstaw jest schemat relacyjny przedstawiony na rysunku 9.6.
RYSUNEK 9.6. Schemat bazy danych dla przykadu obliczania uzna przychodu
121
Klasy operujce danymi uporzdkowane s bardzo podobnie; kadej tabeli odpowiada jeden
modu tabeli. W architekturze .NET reprezentacj struktury bazy danych w pamici zapewnia
obiekt zbioru danych (ang. data set). Wanie na takich obiektach powinny operowa tworzone
klasy. Kada klasa moduu tabeli ma pole typu -. Jest to klasa, ktra w systemie .NET
odpowiada pojedynczej tabeli zbioru danych. Mog z niej korzysta wszystkie moduy tabeli i mona
j traktowa jako wzorzec Layer Supertype (434).
-% ,,,

--2

-%
!-<0
-1,-?-<@2
6
Konstruktor podklasy wywouje konstruktor superklasy korzystajc ze wskazanej nazwy tabeli.

,,,
-
H-7
706
Umoliwia to utworzenie nowego moduu tabeli przez proste przekazanie zbioru danych do konstruktora moduu.

1+
2
Utrzymujemy w ten sposb kod odpowiedzialny za tworzenie zbioru danych poza moduami tabeli, co odpowiada zasadom korzystania z ADO.NET.
Wygodn cech jzyka C# jest indeksator (ang. indexer), ktry umoliwia dostp do wybranego
wiersza danych tabeli w oparciu o klucz gwny.

,,,
-+?!@0
!0

!(
1
!,)
710>672

-, (
?>@2
6
6
Pierwszy fragment kodu, w ktrym implementujemy zachowania, oblicza uznanie przychodu

dla umowy, aktualizujc odpowiednio tabel uzna. Uznawana kwota zaley od produktu, ktrego
dotyczy. Poniewa korzystamy przy tym gwnie z danych tabeli umw, wczamy odpowiedni
metod do klasy umw.

,,,
- !!
0
+
+1?
@2
1
+?7 7@2
!
1+ !-, 2

$

1+$
-, 2
!
1*$

2
122
(
,*$

11$
,9$0

,

*9 !
2
6(
,*$

11$
, 0
?@1 A2

,

?>@*9 !
2

,

?3@
*9 !
,B>2

,

?4@
*9 !
,C>2
6(
,*$

11$
,0
?@1 A2

,

?>@*9 !
2

,

?3@
*9 !
,A>2

,

?4@
*9 !
,B>2
6
++/ 7"(

72
6

?@ -0
+ 1 I-2
+ 1, + 42
! 1+ 8>,>32
?@
1+?-@2

1 J-2
(
1>2=

288
?@1! 2
(
1

2=-288
?@1+ 2

2
6
Cho we wczeniejszych przykadach uywaem w tym miejscu obiektu Money (446), tutaj dla
zrnicowania wprowadziem typ . Metoda alokacji jest podobna jak w przypadku klasy
Money (446).
Do przeprowadzenia takich operacji niezbdne s pewne funkcje zdefiniowane w innych klasach. Musimy mie moliwo pobrania typu kadego produktu. Moliwo t zapewnimy sobie,
wprowadzajc enumeracj typw i metod pobierajc odpowiedni warto.
- $
09$
62
$
,,,
-$
*$
!0

! 1
!?@?7 7@2

$
,$
($
2
6
Metoda *$
hermetyzuje dane tabeli. Oglnie rzecz biorc, bezporedni odczyt sumy
umowy z kolumny tabeli (jak w przykadzie powyej) nie jest najlepszym podejciem. Zasada
hermetyzacji powinna obj poszczeglne kolumny danych. Rozwizanie takie wybraem ze wzgldu
na zaoenie, e pracujemy w rodowisku, w ktrym rne czci systemu korzystaj z bezporedniego
dostpu do zbioru danych. Gdy zbir danych jest przekazywany do interfejsu uytkownika, hermetyzacja rwnie nie jest stosowana. Funkcje dostpu do kolumn stosujemy tylko wtedy, gdy ma to
suy wprowadzeniu dodatkowej funkcjonalnoci, takiej jak konwersja cigu na typ $
.
123
Warto w tym miejscu wspomnie rwnie o tym, e cho w przykadzie stosujemy zbir danych
o nieokrelonych typach (poniewa jest to czciej stosowane na rnych innych platformach),
w rodowisku .NET zaleca si cise okrelanie typw (strona 466).
Kolejn niezbdn funkcj jest wstawianie nowego rekordu uznania przychodu.
!,,,
-!
!
0
+++1-,<++2
!1*</2
++?77@12
++?7
7@1
2
++?7 7@1 2
++?77@1
!,)
70>H672
-,+,++2

2
6
Rwnie ta metoda suy nie tyle hermetyzacji wiersza danych, co przede wszystkim wprowadzeniu
metody w miejsce kilku wierszy kodu, ktre musiayby by powtarzane w rnych miejscach aplikacji.
Drug funkcj jest sumowanie wszystkich przychodw umowy uznanych do okrelonego dnia.
Poniewa korzysta ona z tabeli uzna przychodw, metod definiujemy w odpowiadajcej tej tabeli
klasie.
!,,,
-!" !
#(0

!(
1
!,)
7
10>6<=1K03H6K7

#(2
+?@
+1-, (
2

1>2
(
+
+
+0

81
+?7 7@2
6

2
6
Ten fragment korzysta z bardzo wygodnego mechanizmu ADO.NET, ktry umoliwia (bez uycia
jzyka SQL) definiowanie klauzuli 9: i wybieranie podzbioru danych tabeli, na ktrych maj
zosta wykonane operacje. W praktyce, w tak prostym przykadzie mona pj jeszcze dalej i uy
funkcji agregujcej.
!,,,
-!" 4!
#(0

!(
1
!,)
7
10>6<=1K03H6K7

#(2

! /
17 72
#-L 1-, /
(
2

,< ;>H 2
6
124
Service Layer (warstwa usug)

Randy Stafford
Definiuje granic aplikacji przez wprowadzenie warstwy, ktra okrela zbir dostpnych
operacji i koordynuje odpowiedzi aplikacji dla kadej z nich.
Aplikacje dla przedsibiorstw wymagaj czsto rnych interfejsw danych, na ktrych operuj,
i logiki, ktr implementuj: mechanizmw adowania danych, interfejsw uytkownika, bram
integracji i innych. Pomimo, e s przeznaczone do rnych celw, interfejsy te czsto wymagaj
tych samych mechanizmw interakcji z aplikacj, niezbdnych, aby uzyska dostp i operowa
danymi, jak rwnie do wywoywania funkcji logiki biznesowej. Interakcje te mog by bardzo
zoone, mog obejmowa transakcje operujce na rnych zasobach i wymaga koordynacji wielu
odpowiedzi aplikacji na pojedyncze wywoanie. Kodowanie logiki interakcji w kadym z interfejsw
niezalenie prowadzi wwczas do znacznej iloci powtrze.
Warstwa usug definiuje granic aplikacji Cockburn PloP i zbir operacji dostpnych warstwom klienckim. Hermetyzuje ona logik biznesow, zapewniajc sterowanie transakcjami i koordynacj odpowiedzi aplikacji, generowane przez waciwe implementacje operacji.
SERVICE LAYER (WARSTWA USUG)
125
Na czym polega
Warstwa usug moe by implementowana kilkoma sposobami, z ktrych kady odpowiada przedstawionej powyej charakterystyce. Rnice wystpuj w podziale funkcjonalnoci wspierajcej
interfejs tej warstwy. Zanim przedstawi bliej rne moliwoci 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)
suy do porzdkowania logiki biznesowej. Wielu projektantw wrd nich i ja dzieli logik
biznesow (ang. business logic) na dwa rodzaje: logik dziedziny (ang. domain logic), zwizan
wycznie z dziedzin problemu (jak strategie obliczania uznania przychodu z umowy), i logik
aplikacji (ang. application logic), zwizan z funkcjami aplikacji Cockburn UC (jak powiadamianie administratorw umw i aplikacji zintegrowanych o obliczeniach uzna przychodu). Logik
aplikacji okrela si czasem terminem logika pracy (ang. workflow logic), cho termin praca
(albo przepyw pracy) bywa rnorodnie interpretowany.
Model dziedziny ma t przewag na skryptami transakcji, e dziki zastosowaniu klasycznych wzorcw projektowych sprzyja unikaniu duplikacji kodu dziedziny i uatwia zarzdzanie
zoonoci. Jednak umieszczenie logiki aplikacji w klasach obiektw dziedziny ma kilka niepodanych konsekwencji. Po pierwsze, klasy obiektw dziedziny, ktre zawieraj logik specyficzn dla okrelonej aplikacji i s zalene od jej pakietw, nie mog by uywane w innych aplikacjach. Po drugie, poczenie obu rodzajw logiki w tych samych klasach utrudnia powtrne
zaimplementowanie, gdy przyjdzie taka potrzeba, logiki aplikacji (na przykad w narzdziu do zarzdzania przepywem pracy). Wprowadzenie warstwy usug umoliwia oddzielenie dwch rodzajw logiki biznesowej. Oznacza to nie tylko korzyci typowe dla podziau warstwowego aplikacji, ale rwnie czyste klasy obiektw dziedziny, ktre atwiej przenosi midzy aplikacjami.
Moliwoci implementacji
Dwie podstawowe opcje implementacji to fasada dziedziny i skrypty operacji. Fasada dziedziny (ang. domain facade) to zbir prostych oson modelu dziedziny. Implementujce je klasy
nie zawieraj logiki biznesowej, ktra w caoci pozostaje w modelu dziedziny. Osony wyznaczaj granic aplikacji i zbir operacji, ktre warstwy klienckie mog wykorzystywa do interakcji
z ni.
Skrypty operacji (ang. operation script) to zbir nieco bardziej rozbudowanych klas, ktre
bezporednio implementuj logik aplikacji, delegujc zarazem logik dziedziny do hermetycznych klas obiektw dziedziny. Operacje dostpne klientom warstwy usug s implementowane jako skrypty uporzdkowane wedug obszarw tematycznych logiki. Kada taka klasa stanowi
usug aplikacji, std czsto umieszczane w ich nazwach sowo Service (usuga). Zbir takich
klas tworzy warstw usug. Powinny one by rozszerzeniem klasy Layer Supertype (434), ktra
oglnie definiuje zakres ich funkcji i wsplne zachowania.
Wywoania zdalne
Interfejs warstwy usug ma nisk ziarnisto. Wynika to w oczywisty sposb std, e jest to
zestaw operacji aplikacji, ktre s dostpne dla korzystajcych z niej warstw klienckim. W konsekwencji, klasy warstwy usug do dobrze nadaj si do realizacji wywoa zdalnych.
Z drugiej strony, zdalne wywoania wi si z kosztem rozproszenia obiektw. Wprowadzenie do warstwy usug obiektw Data Transfer Object (366) wymaga zazwyczaj do duo pracy.
Ten dodatkowy koszt warto potraktowa powanie, zwaszcza gdy model dziedziny jest skomplikowany, a interfejs uytkownika rozbudowany pod ktem obsugi zoonych przypadkw aktualizacji
126
danych. Jest to praca znaczca i czasochonna, porwnywalna chyba tylko z mapowaniem obiektowo-relacyjnym. Nigdy nie wolno wic zapomina o pierwszym prawie projektowania dla obiektw rozproszonych (strona 87).
Najrozsdniejszym podejciem do budowy warstwy usug bdzie wic stworzenie metod
przeznaczonych do wywoa lokalnych, ktrych sygnatury operuj obiektami dziedziny. Moliwo wywoa zdalnych mona doda dopiero wtedy, gdy okae si faktycznie niezbdna. Korzystamy wwczas ze wzorca Remote Facade (353), ktry uzupenia gotow warstw, przystosowan
do uytku lokalnego (mona te wprowadzi interfejsy zdalne bezporednio do obiektw warstwy
usug). Jeeli aplikacja jest wyposaona w interfejs przegldarki WWW lub usug WWW, nie
oznacza to jeszcze, e logika biznesowa musi pracowa w innym procesie ni strony serwera czy
usugi sieci Web. W rzeczywistoci, mona oszczdzi sobie pracy i skrci czas reakcji aplikacji
stosujc rozwizanie kolokowane. Nie oznacza to wcale ograniczenia skalowalnoci.
Identyfikacja usug i operacji
Identyfikowanie operacji, ktre powinna zapewnia wyznaczana przez warstw usug granica, jest stosunkowo proste. Wyznaczaj je potrzeby klientw, z ktrych najbardziej znaczcym
(i pierwszym) jest najczciej interfejs uytkownika. Poniewa jest on zaprojektowany pod ktem
przypadkw uycia, punktami wyjcia staj si potrzeby aktorw, opracowane wczeniej przypadki uycia i projekt interfejsu uytkownika aplikacji.
Wiele przypadkw uycia aplikacji korporacyjnej to do nudne operacje utwrz, odczytaj,
aktualizuj, usu dla rnych obiektw dziedziny. Tworzymy wic jeden obiekt pewnego
rodzaju, odczytujemy kolekcj innych, aktualizujemy jeszcze inne itp. Dowiadczenie wykazuje,
e wanie takie przypadki uycia maj swoje miejsce jako wzr dla funkcji warstwy usug.
Cho przypadki uycia prezentuj si stosunkowo prosto, niezbdne do ich realizacji czynnoci
aplikacji s zazwyczaj znacznie ciekawsze. Poza sprawdzaniem poprawnoci danych oraz tworzeniem,
aktualizowaniem i usuwaniem obiektw dziedziny, coraz czciej wymagane jest powiadamianie o wykonanych operacjach zarwno osb, jak i innych aplikacji. Tego rodzaju zdarzenia wymagaj koordynacji i caociowego podejcia do ich przetwarzania. To wanie jest zadaniem warstwy usug.
Nie jest atwo wyznaczy zasady grupowania powizanych operacji warstwy usug. Trudno
tu mwi o gotowych reguach postpowania. W przypadku niewielkiej aplikacji wystarczy moe
jedna taka grupa, nazwana tak samo jak aplikacja. Wiksze aplikacje dzieli si na kilka podsystemw, z ktrych kady zawiera kompletny pion elementw poszczeglnych warstw architektury. W takim przypadku kademu podsystemowi mona przypisa jedn abstrakcj warstwy
usug, dziedziczc nazw po podsystemie, do ktrego dostp zapewnia. Alternatyw moe by
grupowanie wedug partycji modelu dziedziny (np.

, $

) albo zagadnie, z ktrymi zwizane s realizowane zachowania (np. !
).
Implementacja w jzyku Java
Zarwno fasada dziedziny, jak i skrypty operacji mog by implementowane przy uyciu obiektw POJO
lub bezstanowych obiektw bean sesji. Wybieramy tutaj pomidzy atwoci testowania a atwoci
sterowania transakcjami. Zwyke obiekty jzyka Java jest atwiej testowa, poniewa nie wymagaj do
pracy kontenera EJB. Trudniej je natomiast powiza z rozproszonymi, zarzdzanymi kontenerowo
usugami transakcji, zwaszcza przy wywoaniach pomidzy usugami. Obiekty EJB zapewniaj obsug
kontenerowo zarzdzanych transakcji rozproszonych, ale kade uruchomienie lub test musi odbywa si
w rodowisku kontenera. Wybr nie jest wic atwy.
Moj ulubion technik implementacji warstwy usug w J2EE s bezstanowe obiekty session bean EJB 2.0, wyposaone w interfejsy lokalne. Korzystam przy tym ze skryptw operacji, ktre deleguj
do klas obiektw dziedziny, zaimplementowanych jako obiekty POJO. Rozproszone, zarzdzane
kontenerowo transakcje, jakie zapewnia rodowisko EJB, znakomicie uatwiaj implementowanie
warstwy usug przy uyciu bezstanowych obiektw session bean. Wprowadzone w EJB 2.0 interfejsy
lokalne umoliwiaj warstwie usug wykorzystanie cennych usug transakcji, nie zmuszajc zarazem do
wprowadzania obiektw rozproszonych.
127
Omawiajc implementacj w jzyku Java, warto zwrci uwag na rnice midzy wzorcem Service
Layer a wzorcem Session Facade, opisywanym w literaturze J2EE (Alur et al. i Marinescu). Session
Facade ma na celu uniknicie obnienia wydajnoci, wynikajcego z nadmiernej liczby zdalnych wywoa obiektw entity bean. Std osonicie obiektw entity bean obiektami session bean. Service Layer to
wzorzec, ktry dzieli implementacj w celu uniknicia powtrze kodu i uatwienia jego powtrnego
uycia. Jest to wzorzec architektury niezaleny od wykorzystywanej technologii. Warto przypomnie,
e opisany w Cockburn PloP wzorzec granicy aplikacji, ktry by inspiracj dla wzorca Service Layer,
powsta trzy lata wczeniej ni rodowisko EJB. Wzorzec Session Facade moe przypomina w swojej
idei warstw usug, nie jest jednak tym samym.
Kiedy uywamy
Podstawowe korzyci z wprowadzenia warstwy usug to definicja jednolitego zbioru operacji aplikacji,
ktry jest dostpny wielu rodzajom klientw, oraz koordynacja odpowiedzi aplikacji. Odpowied
taka moe wymaga logiki aplikacji, ktra zapewnia caociowe przetwarzanie operacji, oparte na
wielu zasobach transakcyjnych. Aplikacja, ktra ma wicej ni jednego klienta korzystajcego z jej
logiki biznesowej, i realizuje zoone odpowiedzi oparte na wielu zasobach transakcyjnych, jest
niewtpliwie dobrym kandydatem do wprowadzenia warstwy usug z kontenerowo zarzdzanymi
transakcjami, nawet jeeli nie korzysta z architektury rozproszonej.
Prociej jest prawdopodobnie odpowiedzie na pytanie, kiedy nie warto wprowadza warstwy
usug. Nie jest ona zazwyczaj uzasadniona, gdy logika biznesowa aplikacji ma tylko jednego klienta,
na przykad interfejs uytkownika, a jej przypadki uycia nie przewiduj korzystania z wielu zasobw
transakcyjnych. W takich przypadkach do kontroli transakcji i koordynowania odpowiedzi moe posuy mechanizm Page Controller (302). Moe on te delegowa bezporednio do warstwy rda danych.
Gdy tylko pojawia si koncepcja wprowadzenia drugiego klienta lub drugiego zasobu transakcyjnego, warto wprowadzi warstw usug ju na pocztku projektu.
Warto przeczyta
Niewiele napisano dotd o wzorcu Service Layer (124). Jego pierwowzorem by wzorzec granicy
aplikacji, przedstawiony przez Alistair Cockburn (Cockburn PloP). Praca Alpert et al. omawia rol
fasad w systemach rozproszonych. Dla porwnania warto zapozna si z rnymi opisami wzorca
Session Facade Alur et al. i Marinescu. Z zagadnieniem funkcji aplikacji, ktre musz by koordynowane przez warstw usug, powizany jest opis przypadkw uycia jako kontraktu zachowa, przedstawiony w Cockburn UC. Wczeniejsz prac teoretyczn jest Coleman et al., gdzie
mowa o rozpoznawaniu operacji systemowych w metodologii Fusion.

Przedstawi teraz kolejn wersj przykadu, ktry suy nam jako ilustracja od pocztku rozdziau.
Tym razem zaprezentuj na nim zastosowanie wzorca Service Layer, a wic podzia na logik
aplikacji i logik dziedziny. Warstwa usug bdzie miaa posta skryptu operacji, ktry zaimplementujemy najpierw przy uyciu obiektw POJO, a nastpnie obiektw EJB.
128
Rozwiniemy teraz nieco podstawowy scenariusz, aby wprowadzi do niego elementy logiki
aplikacji. Zamy, e przypadki uycia aplikacji wymagaj, aby obliczaniu uzna przychodu dla
umowy towarzyszyo przesanie powiadomienia e-mail do wskazanego administratora umw
oraz opublikowanie przy uyciu oprogramowania typu middleware wiadomoci, ktra zapewni
przekazanie informacji aplikacjom zintegrowanym.
Rozpoczynamy od zmodyfikowania klasy !
z przykadu ilustrujcego
wzorzec Transaction Script (103) tak, aby rozszerzy klas Layer Supertype (434) i wprowadzi
kilka klas Gateway (425), ktre posu do realizacji logiki aplikacji. Bdzie to odpowiada diagramowi klas przedstawionemu na rysunku 9.7. Klasa !
stanie si implementacj warstwy usug opart na obiektach POJO, a jej metody bd reprezentowa dwie dostpne na
granicy aplikacji operacje.
Metody klasy !
realizuj logik aplikacji, delegujc logik dziedziny do klas
obiektw dziedziny, wzitych z przykadu ilustrujcego 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# HE+K78
< -

87,#-" "
" ,72
!!
*+, - !
2
6
-%
!" !
< -
#(0

,

< -
,
!" #(2
6
6
W naszym przykadzie nie bdziemy zajmowa si kwestiami magazynowania danych, ograniczajc si do stwierdzenia, e klasa
implementuje statyczne metody do odczytywania
umw z warstwy rda danych wedug ich numerw. Nazwa jednej z tych metod (
)
E ) sygnalizuje zamiar aktualizacji odczytywanej umowy, co umoliwia mechanizmowi Data Mapper (152)
zarejestrowanie odczytywanego obiektu przy uyciu, na przykad, schematu Unit of Work (169).
RYSUNEK 9.7. Diagram klas POJO dla usugi obliczania uzna przychodu
129
130
Nie bdziemy rwnie opisywa szerzej sterowania transakcjami. Metoda
! jest z natury transakcyjna, poniewa w trakcie jej wykonywania modyfikowane s
trwae obiekty umw (przed dodaniem uzna przychodu); do oprogramowania middleware przekazywane s wiadomoci; wysyane s wiadomoci pocztowe. Wszystkie te odpowiedzi aplikacji
musz by przetwarzane jako cao, bo nie chcemy wysya wiadomoci e-mail lub publikowa
wiadomoci dla innych aplikacji, jeeli zmiany w umowie nie zostay trwale zapisane.
Na platformie J2EE zarzdzanie transakcjami rozproszonymi mona pozostawi kontenerowi EJB. W tym celu implementujemy usugi aplikacji (i obiekty Gateway (425)) jako bezstanowe obiekty session bean, korzystajce z zasobw transakcyjnych. Rysunek 9.8 przedstawia
diagram klas implementacji usugi obliczania uzna przychodu, korzystajcej z interfejsw lokalnych EJB 2.0 i idiomu interfejsu biznesowego (ang. business interface). W tej implementacji
wci korzystamy z klasy Layer Supertype (434), zapewniajcej metody obiektw bean, ktrych
wymaga mechanizm EJB, oraz metody specyficzne dla aplikacji. Jeeli zaoymy, e interfejsy
*+ i !
*+ s rwnie interfejsami biznesowymi odpowiednich bezstanowych obiektw session bean, to sterowanie transakcj rozproszon uzyskamy przez zadeklarowanie metod !, %! i - !
jako transakcyjnych. Metody !
z przykadu opartego na obiektach
POJO zostaj przeniesione w niezmienionej postaci do klasy !
.
Wanym elementem w tym przykadzie jest fakt, e warstwa usug uywa do koordynowania
transakcyjnych odpowiedzi aplikacji zarwno skryptw operacji, jak i klas obiektw dziedziny.
Metoda ! realizuje logik aplikacji wymagan przez przypadki uycia, ale deleguje logik dziedziny do klas obiektw dziedziny. Zastosowanych jest te kilka technik unikania powtrze kodu w skryptach operacji, ktre tworz warstw usug. Cz funkcji jest
przeniesiona do osobnych obiektw Gateway (425), ktre mog by ponownie wykorzystywane
przez zastosowanie delegacji. Layer Supertype (434) zapewnia wygodny dostp do tych obiektw.
Czytelnik mgby stwierdzi, e zastosowanie wzorca Observer i Gang of Four pozwalaoby
uzyska bardziej eleganck implementacj skryptu operacji. Jednak wzorzec Observer byby trudny
do zaimplementowania w bezstanowej i wielowtkowej warstwie usug. Otwarty kod skryptu operacji
okazuje si bardziej przejrzysty i prostszy.
Mona rwnie stwierdzi, e funkcje logiki aplikacji mogyby zosta zaimplementowane w metodach obiektw dziedziny, takich jak
, !, lub nawet w warstwie rda danych, co wyeliminowaoby potrzeb stosowania osobnej warstwy usug. Taka alokacja
funkcji wydaje si jednak niepodana z kilku powodw. Po pierwsze, klasy obiektw dziedziny
gorzej poddaj si prbom ponownego uycia w innych aplikacjach, gdy zawieraj logik specyficzn dla jednego rozwizania (i pozostaj zalene od specyficznych dla aplikacji obiektw (Gateway (425)). Ich zadaniem jest modelowanie czci dziedziny problemu, z ktrymi aplikacja jest
zwizana, co jednak nie oznacza wszystkich funkcji wyznaczanych przez przypadki uycia teje
aplikacji. Po drugie, hermetyzacja logiki aplikacji w wyszej, przeznaczonej wycznie do tego
celu warstwie (czego nie mona powiedzie o warstwie rda danych) uatwia wprowadzanie w niej
zmian. Ich celem moe by choby wprowadzenie motoru zarzdzania przepywem pracy.
Jako wzorzec organizacji warstwy logicznej aplikacji korporacyjnej, Service Layer czy w sobie skrypty i klasy obiektw dziedziny, korzystajc z najlepszych cech obu podej. Jego implementacja moe by przeprowadzona rnymi metodami: przy uyciu fasad dziedziny lub skryptw
operacji, obiektw POJO lub obiektw bean sesji (albo jednych i drugich), z orientacj na wywoania
lokalne lub zdalne (albo oba rodzaje). Co najwaniejsze, niezalenie od tego, ktr implementacj
wybierzemy, bdzie ona hermetyczn realizacj logiki biznesowej aplikacji, zapewniajc spjny
interfejs tej logiki rnym warstwom klienckim.
RYSUNEK 9.8. Diagram klas EJB dla usugi obliczania uzna przychodu
131

Architektura Systemów Zarządzania Przedsiębiorstwem. Wzorce Projektowe

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Architektura Systemów Zarządzania Przedsiębiorstwem. Wzorce Projektowe

Transféré par

Droits d'auteur :

Formats disponibles

IDZ DO

Wykorzystaj wzorce projektowe w pracy nad oprogramowaniem

Korzystajc z zawartych w ksice wzorcw,

Wzorce mapowania struktury...........................................................................................................................49

Row Data Gateway (Brama danych wiersza).................................................................................................140

Association Table Mapping (Odwzorowanie do tabeli asocjacji) ..................................................................226

Registry (Rejestr) ...........................................................................................................................................438

Wzorce logiki dziedziny

Transaction Script (Skrypt transakcji)

9. WZORCE LOGIKI DZIEDZINY

RYSUNEK 9.1. Skrypty transakcji jako polecenia

TRANSACTION SCRIPT (SKRYPT TRANSAKCJI)

Problem obliczania przychodu

9. WZORCE LOGIKI DZIEDZINY

Przykad: uznanie przychodu (Java)

TRANSACTION SCRIPT (SKRYPT TRANSAKCJI)

Drugi skrypt suy do podsumowania danych przekazanych przez bram.

9. WZORCE LOGIKI DZIEDZINY

Druga procedura to osona instrukcji < .

DOMAIN MODEL (MODEL DZIEDZINY)

Domain Model (model dziedziny)

9. WZORCE LOGIKI DZIEDZINY

DOMAIN MODEL (MODEL DZIEDZINY)

Implementacja w jzyku Java

9. WZORCE LOGIKI DZIEDZINY

obejmujce sprawdzanie poprawnoci, obliczenia i derywacje, zdecydowanie powinny skania do

Przykad: uznanie przychodu (Java)

DOMAIN MODEL (MODEL DZIEDZINY)

RYSUNEK 9.3. Diagram klas dla przykadu modelu dziedziny

9. WZORCE LOGIKI DZIEDZINY

 -% 

DOMAIN MODEL (MODEL DZIEDZINY)

9. WZORCE LOGIKI DZIEDZINY

Obiektowa zasada przekazywania od obiektu do obiektu przenosi zachowanie do tego z nich,

TABLE MODULE (MODU TABELI)

Table Module (modu tabeli)

9. WZORCE LOGIKI DZIEDZINY

Najbardziej przejrzystym przykadem rozwizania opartego na moduach tabel bdzie sytuacja,

TABLE MODULE (MODU TABELI)

RYSUNEK 9.5. Typowe interakcje warstw otaczajcych modu tabeli

9. WZORCE LOGIKI DZIEDZINY

Przykad: uznanie przychodu (C#)

TABLE MODULE (MODU TABELI)

Konstruktor podklasy wywouje konstruktor superklasy korzystajc ze wskazanej nazwy tabeli.

Pierwszy fragment kodu, w ktrym implementujemy zachowania, oblicza uznanie przychodu

1+  ! -, 2

9. WZORCE LOGIKI DZIEDZINY

TABLE MODULE (MODU TABELI)

9. WZORCE LOGIKI DZIEDZINY

Service Layer (warstwa usug)

SERVICE LAYER (WARSTWA USUG)

9. WZORCE LOGIKI DZIEDZINY

SERVICE LAYER (WARSTWA USUG)

Przykad: uznanie przychodu (Java)

9. WZORCE LOGIKI DZIEDZINY

SERVICE LAYER (WARSTWA USUG)

9. WZORCE LOGIKI DZIEDZINY

SERVICE LAYER (WARSTWA USUG)

Vous aimerez peut-être aussi

Druga procedura to osona instrukcji < .

-%

1+ !-, 2