Jsfecg 2

Idź do JavaServer Faces i Eclipse
Galileo. Tworzenie
• Spis treści
• Przykładowy rozdział aplikacji WWW
Autor: Andrzej Marciniak
Katalog książek ISBN: 978-83-246-2656-4
Format: 158×235, stron: 384
• Katalog online
• Zamów drukowany
katalog
• Jak projektować estetyczne i wygodne interfejsy użytkownika aplikacji WWW?
Twój koszyk • Od czego zacząć projekt wykorzystujący JavaServer Faces?
• Co oferuje środowisko Eclipse Galileo, a co narzędzia Web Tools Platform?
Dobry interfejs aplikacji WWW to połowa jej sukcesu. Osiągnij go z JavaServer Faces! Język Java
• Dodaj do koszyka od lat zdobywa i ugruntowuje swoją popularność wśród programistów i twórców aplikacji WWW,
a rozmaite platformy i rozwiązania, w których jest on wykorzystywany, zostały na stałe włączone
Cennik i informacje do pakietu narzędzi stosowanych przez wielu z nich na co dzień. Jednym z najbardziej popularnych
tego typu narzędzi jest JavaServer Faces. Można dzięki niemu w prosty sposób tworzyć interfejsy
użytkownika aplikacji, wykorzystujące platformę Java EE. Ten spójny i kompletny szkielet
• Zamów informacje programistyczny jest obecnie najbardziej elastycznym, najlepiej dopracowanym i najprostszym
o nowościach w użyciu rozwiązaniem, opartym na technologii serwletów.
• Zamów cennik Jednak „najprostszy” wcale nie musi oznaczać „prosty”, o czym z pewnością miało okazję
przekonać się wielu studentów kierunków informatycznych i profesjonalnych programistów,
Czytelnia którzy postanowili praktycznie zapoznać się z możliwościami tej technologii. Nieocenioną
pomocą okaże się dla nich książka „JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW”,
dzięki której można uniknąć wielu typowych błędów i nauczyć się biegle korzystać z JSF,
• Fragmenty książek zdobywając przy tym kompletną wiedzę na temat mechanizmów i rozwiązań zapewniających
online działanie tej platformy. Co więcej, opisano tu nie tylko samą technologię, lecz również sposób jej
praktycznego wykorzystania w konkretnych projektach, co w przyszłości zaowocuje z pewnością
opracowaniem niejednej doskonałej i cieszącej oko aplikacji WWW.
• Mechanizmy działania aplikacji WWW i sposoby ich projektowania w oparciu o język Java
• Podstawowe informacje na temat szkieletu programistycznego JSF
• Realizacja praktycznego projektu z wykorzystaniem JavaServer Faces
• Rozszerzanie standardowej implementacji JSF i tworzenie niestandardowych interfejsów
użytkownika
• Opis środowiska programistycznego Eclipse Galileo oraz pakietu narzędzi Web Tools
Platform
Naucz się szybko i sprawnie tworzyć rozbudowane interfejsy użytkownika aplikacji
Kontakt WWW za pomocą szkieletu programistycznego JavaServer Faces
Helion SA
ul. Kościuszki 1c
44-100 Gliwice
tel. 32 230 98 63
e-mail: helion@helion.pl
© Helion 1991–2010
Spis treci
Wstp .............................................................................................. 7
Geneza ksiki .................................................................................................................. 7
Cele .................................................................................................................................. 9
Czytelnicy ....................................................................................................................... 10
Ukad zagadnie ............................................................................................................. 10
Materiay pomocnicze .................................................................................................... 11
Podzikowania ................................................................................................................ 12
Rozdzia 1. Przed przystpieniem do pracy z JSF ............................................... 13
1.1. Dlaczego JSF? ......................................................................................................... 13
1.1.1. Wersje JSF ................................................................................................... 15
1.2. JSF i Java EE (J2EE) ............................................................................................... 17
1.2.1. Serwlety i strony JSP ................................................................................... 19
1.2.2. Technologie prezentacji ............................................................................... 23
1.2.3. MVC w aplikacjach webowych ................................................................... 27
1.2.4. Implementacja MVC w JSF ......................................................................... 32
1.2.5. Kluczowe elementy JSF — podsumowanie ................................................. 38
1.3. Pierwsza aplikacja JSF w rodowisku Eclipse ......................................................... 38
1.3.1. Instalacja kontenera serwletów .................................................................... 40
1.3.2. Instalacja rodowiska Eclipse Galileo .......................................................... 40
1.3.3. Integracja kontenera serwletów ze rodowiskiem Eclipse ........................... 43
1.3.4. Tworzenie projektu JSF ............................................................................... 44
1.3.5. Praca z JSF w oknie roboczym .................................................................... 48
1.3.6. Definiowanie modelu ................................................................................... 53
1.3.7. Definiowanie komponentu wspierajcego ................................................... 54
1.3.8. Utworzenie strony do wprowadzania danych ............................................... 56
1.3.9. Utworzenie strony do wywietlania wyniku ................................................ 59
1.3.10. Deklarowanie regu nawigacji .................................................................... 62
1.3.11. Uruchamianie aplikacji .............................................................................. 63
1.3.12. Podsumowanie przykadu .......................................................................... 65
Rozdzia 2. Planowanie, modelowanie i projektowanie aplikacji JSF
na platformie Java EE ..................................................................... 67
2.1. Modelowanie interfejsu uytkownika przy wykorzystaniu techniki scenopisu ....... 68
2.1.1. Przypadki uycia .......................................................................................... 69
2.1.2. Model ekranów interfejsu uytkownika ....................................................... 70
2.1.3. Model nawigacji .......................................................................................... 72
2.1.4. Prototypy ekranów ....................................................................................... 73
2.1.5. Diagram maszyny stanowej ......................................................................... 75
4 JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW
2.2. Warstwa biznesowa ................................................................................................. 77

2.2.1. Rola i elementy warstwy biznesowej ........................................................... 77
2.2.2. Interfejs do warstwy trwaoci danych ......................................................... 85
2.3. Organizacja kodu aplikacji w Eclipse ...................................................................... 95
2.3.1. Projekty i moduy Java EE w Eclipse .......................................................... 95
2.3.2. Zastosowanie projektu uytkowego
do przechowywania kodu warstwy biznesowej .......................................... 96
2.3.3. Moduy zalene ............................................................................................ 99
Rozdzia 3. Uywanie JSF ............................................................................... 101
3.1. Komponenty zarzdzane ........................................................................................ 101
3.1.1. Deklaracja komponentu ............................................................................. 102
3.1.2. Zasig komponentów ................................................................................. 105
3.1.3. Inicjalizacja waciwoci komponentów .................................................... 106
3.1.4. Odwoania do komponentów zarzdzanych ............................................... 113
3.1.5. Komponenty referowane ............................................................................ 115
3.1.6. Komponenty wspierajce ........................................................................... 116
3.1.7. Jzyk wyrae UEL ................................................................................... 118
3.1.8. Konfiguracja komponentów i innych zasobów .......................................... 123
3.2. Obsuga zdarze .................................................................................................... 127
3.2.1. Typy zdarze i metody ich obsugi ............................................................ 127
3.2.2. Natychmiastowe wykonywanie metod obsugi zdarze ............................. 136
3.2.3. Parametryzacja komponentów UI .............................................................. 137
3.3. Nawigacja .............................................................................................................. 140
3.3.1. Definiowanie regu nawigacji .................................................................... 140
3.3.2. Nawigacja statyczna i dynamiczna ............................................................ 143
3.3.3. Rozstrzyganie niejednoznacznoci w reguach .......................................... 144
3.3.4. Przekierowanie i nawigacja poza JSF ........................................................ 144
3.4. Przetwarzanie pakietów zasobów i internacjonalizacja ......................................... 146
3.4.1. Lokalizatory ............................................................................................... 147
3.4.2. Pakiety zasobów ........................................................................................ 150
3.4.3. Pakiety komunikatów ................................................................................. 154
3.4.4. Internacjonalizacja w warstwie biznesowej ............................................... 157
3.5. Konwersja .............................................................................................................. 159
3.5.1. Standardowe konwertery ............................................................................ 159
3.5.2. Obsuga bdów konwersji ......................................................................... 162
3.6. Walidacja ............................................................................................................... 164
3.6.1. Implementacja metod walidacji ................................................................. 165
3.6.2. Standardowe walidatory ............................................................................. 168
3.6.3. Kombinowanie rónych walidatorów ........................................................ 168
3.6.4. Wymuszanie wprowadzania danych .......................................................... 169
3.6.5. Pomijanie weryfikacji ................................................................................ 169
3.7. Standardowe znaczniki i komponenty UI .............................................................. 169
3.7.1. Komponenty i znaczniki biblioteki html .................................................... 170
3.7.2. Komponenty i znaczniki biblioteki core .................................................... 201
Rozdzia 4. Dopasowywanie JSF ..................................................................... 211
4.1. Przetwarzanie da .............................................................................................. 211
4.1.1. Scenariusze obsugi da ......................................................................... 211
4.1.2. Standardowy cykl przetwarzania dania JSF ........................................... 214
4.1.3. Kolejka zdarze ......................................................................................... 225
4.1.4. Kolejka komunikatów ................................................................................ 228
4.2. Konfigurowanie i rozszerzanie standardowej implementacji ................................. 229
4.2.1. Infrastruktura aplikacji JSF ........................................................................ 229
4.2.2. Mechanizm nawigacji ................................................................................ 238
Spis treci 5
4.2.3. Mechanizm zarzdzania widokami ............................................................ 238

4.2.4. Mechanizm zarzdzania stanem ................................................................. 239
4.2.5. Mechanizm przetwarzania wyrae EL ..................................................... 239
4.2.6. Mechanizm obsugi akcji ........................................................................... 243
4.3. Model komponentów ............................................................................................. 243
4.3.1. Struktura klas ............................................................................................. 244
4.3.2. Identyfikatory komponentów ..................................................................... 251
4.4. Praktyczne zastosowania obiektów PhaseListener ................................................ 255
4.4.1. Wzorzec POST-Redirect-GET ................................................................... 256
4.4.2. Generowanie danych binarnych ................................................................. 258
4.5. Zoone tabele ....................................................................................................... 260
4.5.1. Modele danych ........................................................................................... 260
4.5.2. Przykad tabeli interaktywnej ..................................................................... 261
4.6. JSF i bezpieczestwo ............................................................................................. 264
4.6.1. Bezpieczestwo zarzdzane przez kontener ............................................... 265
4.6.2. Bezpieczestwo zarzdzane przez aplikacj .............................................. 270
Rozdzia 5. Tworzenie komponentów uytkownika ........................................... 275
5.1. Komponenty interfejsu uytkownika (UI) ............................................................. 275
5.1.1. Implementacja komponentu ....................................................................... 276
5.1.2. Przechowywanie stanu komponentu .......................................................... 280
5.1.3. Rejestracja komponentu ............................................................................. 282
5.1.4. Generowanie i obsuga zdarze ................................................................. 282
5.1.5. Integracja z JSP .......................................................................................... 284
5.2. Renderery .............................................................................................................. 289
5.2.1. Podstawy implementacji rendererów ......................................................... 290
5.2.2. Renderery i JavaScript ............................................................................... 291
5.2.3. Rejestracja rendererów ............................................................................... 295
5.3. Konwertery ............................................................................................................ 296
5.3.1. Podstawy implementacji konwerterów ...................................................... 297
5.3.2. Rejestracja konwerterów ............................................................................ 300
5.3.3. Integracja konwerterów z JSP .................................................................... 302
5.4. Walidatory ............................................................................................................. 304
5.4.1. Podstawy implementacji walidatorów ....................................................... 305
5.4.2. Rejestracja walidatorów ............................................................................. 306
5.4.3. Integracja walidatorów z JSP ..................................................................... 308
5.5. Komponenty JSF i AJAX ...................................................................................... 309
5.5.1. Podstawy AJAX-a ...................................................................................... 310
5.5.2. Biblioteka AJAX4JSF ................................................................................ 313
5.5.3. Biblioteki AJAX-a ..................................................................................... 315
Rozdzia 6. Narzdzia wsparcia i integracja z innymi szkieletami ..................... 327
6.1. Narzdzia Web Tools Platform .............................................................................. 327
6.1.1. Zarzdzanie serwerem aplikacji ................................................................. 328
6.1.2. Monitorowanie portów ............................................................................... 330
6.1.3. Narzdzia uatwiajce prac z bazami danych ........................................... 333
6.2. Technologie widoku .............................................................................................. 338
6.2.1. Facelets ...................................................................................................... 339
6.2.2. Apache Tiles 2 ........................................................................................... 344
6.2.3. Smile .......................................................................................................... 350
Dodatek A Standardy kodowania IANA ........................................................... 353

Dodatek B Zaoenia JSF 2.0 ......................................................................... 355
Dodatek C Wspólne elementy konfiguracji ..................................................... 357
Dodatek D Komunikaty o bdach .................................................................. 359
Komunikaty o bdach komponentów .......................................................................... 359
Komunikaty o bdach konwerterów ............................................................................ 359
Komunikaty o bdach walidatorów ............................................................................. 360
Dodatek E Atrybuty przekazywane HTML i zdarzenia DHTML ........................... 361
Literatura ..................................................................................... 363
Skorowidz .................................................................................... 365
Rozdzia 2.
Planowanie, modelowanie
i projektowanie aplikacji
JSF na platformie Java EE
Po zapoznaniu si z podstawowymi wiadomociami na temat architektury i moliwo-
ci szkieletu JSF moemy przej do zagadnie zwizanych z wytwarzaniem realnych
aplikacji WWW w rodowisku programistycznym Eclipse Galileo. W niniejszym
rozdziale wybrane fazy wytwarzania aplikacji s zilustrowane na przykadzie Inter-
netowego Systemu Recenzowania Publikacji (w skrócie ISRP), przeznaczonego do
zapewnienia obsugi informatycznej pracy redakcji czasopism naukowych oraz
wspomagania organizacji konferencji naukowych. Zakres funkcjonalnoci projekto-
wanego systemu obejmuje obsug rejestracji artykuów zgaszanych przez autorów,
proces recenzji artykuów oraz administrowanie kontami uytkowników.
Nie jest intencj autora zamieszczenie w tym miejscu penej dokumentacji systemu ISRP
jako zoonego studium przypadku uycia JSF (ang. case study), ale raczej przedsta-
wienie pewnych praktyk projektowych zwizanych z architektur i projektowaniem
aplikacji JSF na platformie Java EE. Prezentowane rozwizania s wypadkow do-
wiadcze wielu osób w zakresie wykorzystania szkieletu JSF do wytwarzania war-
stwy prezentacji w aplikacjach o architekturze wielowarstwowej. Szczególna uwaga
powicona jest wybranym aspektom zwizanym z czynnociami fazy przedimple-
mentacyjnej projektu, takim jak modelowanie interfejsu uytkownika oraz projekto-
wanie aplikacji oparte na architekturze wielowarstwowej. Zamieszczone w tym rozdziale
model i zaoenia projektowe bd rozwijane w dalszej czci ksiki i stanowi jed-
noczenie odniesienie dla kolejnych przykadów ilustrujcych elementy technologii JSF.
2.1. Modelowanie interfejsu

uytkownika przy wykorzystaniu
techniki scenopisu
Jako modelu projektowanego systemu czsto decyduje o powodzeniu projektu in-
formatycznego, a jego najbardziej podan cech jest kompromisowo . Model po-
winien by jednoczenie zrozumiay dla klientów, którzy na jego podstawie oceniaj
funkcjonalno systemu, jak te zawiera wszystkie niezbdne dane dla zespou pro-
jektowego, który z niego korzysta w fazie projektowania. Z jednej strony model powinien
by dopasowany do technologii stosowanych w fazach projektowania i implementacji
(przy zaoeniu, e s one znane wczeniej i wynikaj np. z wymaga niefunkcjonal-
nych), a jednoczenie nie powinien wymaga rozlegej wiedzy na ich temat od ana-
lityków wytwarzajcych model.
Ze wzgldu na komponentowy charakter szkieletu JSF, scenopis wydaje si technik

modelowania, która doskonale spenia opisane wyej kryteria. Scenopis specyfikuje
model zawierajcy analiz funkcjonaln, komponenty funkcjonalne oraz interakcje
pomidzy nimi na ekranach oraz przepywy i projekty ekranów. Najwiksz zalet
scenopisu jest to, e jest on zrozumiay dla osób spoza brany informatycznej, co za-
pewniaj diagramy przypadków uycia i prototypy ekranów. W dalszej czci roz-
dziau zaprezentowane zostan poszczególne elementy scenopisu, ilustrowane wybra-
nymi fragmentami modelu aplikacji ISRP.
Scenopis i metodyki modelowania,

projektowania i dokumentowania systemów informatycznych
Metodyki wytwarzania systemów informatycznych stanowi jeden z gównych nur-
tów inynierii oprogramowania. Obecnie standardowym narzdziem do modelowania
systemów informatycznych jest jzyk UML w wersji 2.1, który stanowi jednoczenie
system wizualizacji, specyfikowania oraz dokumentowania elementów systemu in-
formatycznego. UML jest uywany wraz z jego reprezentacj graficzn — jego ele-
mentom przypisane s symbole, które wizane s ze sob na diagramach. Ze wzgldu
na to e UML zosta stworzony z myl o opisie wiata w analizie obiektowej, jego
specyfikacja nie definiuje gotowych rozwiza dla specyficznych zastosowa, takich
jak modelowanie interfejsu uytkownika. Poniewa nie powsta zunifikowany stan-
dard dla modelowania zachowania i struktury aplikacji WWW, np. w zakresie mode-
lowania nawigacji, przepywów sterowania na ekranach czy projektów ekranów, ró-
ne organizacje i firmy forsuj wasne rozszerzenia jzyka UML w tym zakresie.
Opierajc si na UML, stworzono metodyk projektowania oprogramowania RUP

(Rational Unified Process), która definiuje szablon procesu iteracyjnego wytwarzania
oprogramowania opracowany przez firm Rational Software Corporation. Szablon
RUP pozwala na korzystanie z jego elementów w zalenoci od potrzeb projektowych.
Sporód najlepszych praktyk i zasad inynierii oprogramowania, które s w nim za-
warte, warto wskaza do istotne z punktu widzenia specyfiki aplikacji tworzonych
Rozdzia 2. i Planowanie, modelowanie i projektowanie aplikacji JSF na platformie Java 69
w JSF zarzdzanie wymaganiami (ang. Requirement Management), uywanie archi-

tektury bazujcej na komponentach (ang. Component-based Architecture) czy gra-
ficzne projektowanie oprogramowania.
Scenopis (ang. storyboard) jest modelem projektowym, zwykle tworzonym przez

analityków biznesowych i projektantów interfejsu uytkownika, dostarczonym ze-
spoowi deweloperów jako cz specyfikacji funkcjonalnej. Idea scenopisu wywodzi
si z przedstawionej wyej metodyki RUP, która definiuje m.in. model projektowania
interakcji oparty na dowiadczeniu uytkownika (ang. User-eXperience — UX) w po-
staci ekranów, ich dynamicznej zawartoci i sposobu nawigacji. Typowy scenopis
zawiera pi elementów:
przypadki uycia opisujce wymagania funkcjonalne i przepywy zdarze,
model ekranów UI specyfikujcy ekrany, komponenty i elementy UX,
diagram nawigacji ilustrujcy zwizki pomidzy ekranami (przede wszystkim
reguy nawigacji), oparty na notacji graficznej diagramu klas,
makiety ekranów (ang. mock-up) pokazujce szczegóowo elementy
funkcjonalne interfejsu GUI, tj. kontrolki i ich rozmieszczenie,
diagramy maszyny stanowej dla kadego ekranu ilustrujce interakcj warstwy
kontrolera ekranu z warstw modelu aplikacji.
2.1.1. Przypadki uycia

Wygodnym narzdziem stosowanym na potrzeby identyfikacji i dokumentacji wyma-
ga funkcjonalnych s diagramy przypadków uycia (ang. Use Case — UC) w jzy-
ku UML. Ilustruj one funkcjonalno systemu poprzez wyszczególnienie i przedsta-
wienie za pomoc symboli graficznych: aktorów inicjujcych dziaania, przypadków
uycia systemu oraz wystpujcych pomidzy nimi zwizków. Dziki swojej prosto-
cie oraz abstrahowaniu od rozwiza technicznych, diagramy przypadków uycia s
zrozumiae nawet dla osób, które nie posiadaj wyksztacenia informatycznego. Z zao-
enia stanowi one czytelne narzdzie pozwalajce na komunikacj pomidzy twórcami
systemu i jego potencjalnymi odbiorcami czy inwestorami. Podsumowujc, przypadki
uycia opisuj, co system powinien robi , a nie jak ma to robi .
Na rysunku 2.1 przedstawiono diagram przypadków uycia modelujcy aktorów, przy-

padki uycia oraz powizania pomidzy nimi, wystpujce w systemie ISRP. Sche-
matyczny rysunek postaci ludzkiej zoony z kilku kresek jest symbolem graficznym
aktora, definiujcego spójny zbiór ról odgrywanych przez uytkowników przypadku
uycia w czasie jego realizacji. Przypadki uycia oznaczone s przy wykorzystaniu
wypenionych elips, a ich realizacje zwykymi liniami. Relacje rozszerzania i zawie-
rania dla przypadków uycia opisane s przy zastosowaniu stereotypów umieszczo-
nych w cudzysowach ostroktnych. Relacje uogólniania (w sensie zwizku taksono-
micznego, opisujcego dziedziczenie cech) przedstawione zostay za pomoc linii
zakoczonych strzak z pustym grotem.
Wywietl szczegóy
Zaloguj Odzyskaj haso Edytuj dane osobowe
recenzji
Autor
(from Actors)
Poka szczegóy
pracy
Dodaj prac
Uytkownik
uwierzytelniony
Wywietl list prac
(from Actors) Zarejestruj
«extend»
Edytuj prac
«include»
Recenzent
(from Actors)
Dodaj recenzj
Zarzdzaj pracami
Wywietl list
recenzji
Przypisz recenzenta
do pracy
Dodaj recenzenta
Administrator
Zarzdzaj Wywietl list
(from Actors) uytkownikami «include» uytkowników
Rysunek 2.1. Diagram przypadków uycia dla ISRP
Dokadny opis wykorzystania diagramów UC do modelowania funkcjonalnoci sys-

temu Czytelnik znajdzie w ksice Jzyk UML 2.0 w modelowaniu systemów infor-
matycznych, a wyczerpujcy opis scenariuszy przypadków uycia (tekstowej formy
prezentacji UC) znajduje si w ksice Writing Effective Use Cases1.
2.1.2. Model ekranów interfejsu uytkownika

Model ekranów UI stanowi centralny punkt wyjciowy dla równolegego rozwoju apli-
kacji, prowadzonego w zespoach projektantów stron WWW i programistów aplikacji,
stanowic jednoczenie interfejs umoliwiajcy integracj kodu wytwarzanego przez
1
Polskie wydanie: Alistair Cockburn, Jak pisa efektywne przypadki uycia, tum. Krzysztof Stencel,
Warszawa 2004.
oba zespoy. Model ekranów UI definiuje zbiór ekranów (wraz z ich zawartoci) nie-
zbdnych do zrealizowania wymaga funkcjonalnych okrelonych przez przypadki
uycia. W przypadku zawartoci ekranów model definiuje wycznie elementy funk-
cjonalne, jakie powinny znale si na nich, bez okrelania szczegóów dotyczcych
typów kontrolek (np. pola tekstowego albo listy rozwijanej) czy ich rozmieszczenia.
W technice scenopisów standardowym elementom UML nadawane s nowe znaczenia

poprzez uycie stereotypów przedstawionych w tabeli 2.1.
Tabela 2.1. Stereotypy modelu UI wykorzystywane w technice scenopisów

Stereotyp Rozszerzany element UML Reprezentuje
Screen Class Ekran (w postaci strony WWW).
Fragment ekranu (strony WWW) przeznaczony do
Compartment Class wykorzystania na wielu stronach aplikacji WWW
(definiujcy sekcj strony np. stopk, nagówek itp.).
Form Class Formularz strony WWW.
Input Attribute Pole wejciowe formularza.
Submit Operation Element zatwierdzajcy formularz i generujcy akcj.
Statyczne informacje takie jak etykiety, obrazki czy panele nie s w ogóle reprezen-
towane w modelu UI. Dane biznesowe s przedstawiane na ekranie przy uyciu atry-
butów. Jeli atrybut opatrzony jest stereotypem <<input>>, oznacza to, e suy on do
wprowadzania danych. Peny opis atrybutu prezentowany jest wedug nastpujcego
formatu: widoczno nazwa :typ liczebno =domylna_warto {waciwoci}. Zaó-
my, e mamy ekran sucy do tworzenia konta nowego uytkownika, dostpny wy-
cznie dla administratora systemu. Pole suce do wprowadzania uprawnie dla no-
wego uytkownika moe zosta opisane w nastpujcy sposób:
<<input>> +role :String 1 =reviewer {user.role==admin}
Powyszy zapis informuje nas, e atrybut role reprezentuje pole wejciowe dla da-
nych typu String, wypeniane przez uytkowników z uprawnieniami administratora.
Widoczno elementu okrela, czy jego zawarto jest wywietlana na ekranie (+),
czy te jest ukryta (-). Nazwa atrybutu powinna identyfikowa pole wprowadzania danych
(np. warto atrybutu name dla odpowiedniego pola formularza). Typem atrybutu mo-
e by dowolny typ prymitywny lub obiektowy, wcznie z abstrakcyjnymi typami
danych, reprezentujcymi zoone struktury danych (takie jak listy czy mapy, które
mog by reprezentowane przez klasy abstrakcyjne List bd Map). Pozostae waci-
woci atrybutu s opcjonalne i nie musz by definiowane. Liczebno okrela, ile in-
stancji elementu moe by renderowanych na ekranie, warto domylna jest wartoci
uywan dla elementów, które nie s inicjowane, a nawiasy klamrowe umoliwiaj
zamieszczenie dodatkowych waciwoci bd ogranicze dotyczcych atrybutu, np.
w zakresie dostpu do pola danych.
Zdarzenia generowane przez interfejs uytkownika oraz akcje uytkownika reprezen-

towane s za pomoc operacji. Jeli operacja jest dodatkowo opatrzona stereotypem
<<submit>>, oznacza to, e wskazany element UI suy do zatwierdzania formularza
i generowania akcji, której wynik moe wpywa na nawigacj aplikacji. Peny opis ope-
racji prezentowany jest wedug nastpujcego formatu: widoczno nazwa (lista_
parametrów) :zwracany_typ {waciwoci}. Na przykad element wyzwalajcy akcj
polegajc na przejciu do okna edycji biecego uytkownika moe by opisany w na-
stpujcy sposób:
<<submit>> + edit ():String {current.user==notEmpty}
Nazwa operacji powinna by powizana z nazw metody sucej do obsugi zdarze-

nia wygenerowanego przez operacj lub nazw powizanego z operacj pola (np. gdy
operacja dotyczy walidacji danych wprowadzanych do pola wejciowego po stronie
klienta). Widoczno elementu okrela, czy akcja ma by podjta po stronie klienta (-),
czy po stronie serwera (+). Waciwoci dodatkowo charakteryzujce operacje za-
mieszczane s w opcjonalnych nawiasach klamrowych.
Na rysunku 2.2 zaprezentowano model ekranu realizujcego dwa przypadki uycia

systemu ISRP — rejestracj nowego uytkownika i edycj danych uytkownika uwie-
rzytelnionego. Obie funkcjonalnoci systemu s do podobne i operuj na jednym
zbiorze danych, wic do ich obsugi zamodelowany zosta jeden ekran. Ekran skada
si z trzech czci: nagówka (topMenu) zawierajcego przyciski nawigacji, menu dla
uwierzytelnionych uytkowników (leftMenu) i formularza danych uytkownika. W przy-
padku rejestracji nowego uytkownika elementy menu leftMenu oraz przycisk zapi-
sywania formularza nie s widoczne, podobnie jak przyciski nawigacji (patrz rysunek
2.4). Z kolei w przypadku korzystania z ekranu przez administratora wszystkie jego
elementy s widoczne.
2.1.3. Model nawigacji

W technice scenopisów diagramy nawigacji nie koncentruj si na konkretnym prze-
pywie zdarze, ale pokazuj zwizki pomidzy ekranami. Model nawigacji zawiera
graficzn ilustracj przepywów nawigacji dla wszystkich przypadków uycia. Prze-
pywy nawigacji dla poszczególnych przypadków mog by prezentowane na od-
dzielnych diagramach bd jednym diagramie zbiorczym, jak pokazano na rysunku
2.3. Jak mona zauway , przedstawiony diagram nawigacji jest bardziej szczegóowy
ni opisana w rozdziale 1. graficzna reprezentacja regu nawigacji w Eclipse WTP.
Niemniej podczas tworzenia diagramu mona wykorzysta gotowe obiekty ekranów,
stanowice zawarto utworzonego wczeniej modelu ekranów interfejsu uytkownika.
Wystpujce na diagramie asocjacje skierowane wskazuj kierunek przepywu stero-

wania pomidzy dwoma ekranami. W szczególnych przypadkach asocjacje mog by
wyprowadzane do formularza (<<form>>), ale zawsze miejscem docelowym jest ekran.
Kada asocjacja powinna posiada powizan z docelowym ekranem unikatow na-
zw, która bdzie moga zosta wykorzystana podczas definiowania regu nawigacji
JSF (jako warto elementu <from-outcome>).
«screen» «compartment»
addEditUser includes::leftMenu
+ globalMessage: String [0..*]
«submit»
+ addPaper {user.role==author}() : String
+ addUser {user.role==admin}() : String
+ allPapersList {user.role==admin}() : String
+ authorsPapersList {user.role==author}() : String
+ editAccount{currentUser==notEmpty}(): String
+ reviewersPapersList {user.role==reviewer}() : String
+ usersList {user.role==admin}() : String
«form»
addEditUserForm
«input» «compartment»
+ city: text includes::topMenu
+ country: select
+ department: text + userName {user==authorized}: String
+ firstName: text
+ gender: radio + english() : void
+ lastName: text + polish() : void
+ password: text «submit»
+ phone: text + login {user==notAuthorized}() : String
+ role {user.role==admin}: select + logout {user==authorized}() : String
+ street: text + registration {user==notAuthorized}() : String
+ title: text
+ zipCode: text
«submit»
+ save {currentUser==notEmpty}() : String
+ registration {currentUser==empty}() : String
Rysunek 2.2. Model ekranu rejestracji i edycji danych uytkownika
2.1.4. Prototypy ekranów

Zrozumiay, ergonomiczny i przejrzysty interfejs uytkownika jest jednym z kluczo-
wych czynników decydujcych o sukcesie aplikacji WWW. Konsultowanie wygldu
interfejsu przez potencjalnych uytkowników systemu w fazie przedimplementacyjnej
lub w trakcie implementacji pozwala ten sukces osign . Celem przeanalizowania
preferencji uytkowników w zakresie funkcjonalnoci interfejsu stosuje si tzw. pro-
totypowanie, polegajce na wytwarzaniu makiet ekranów (ang. mock-up). Pojcie
makiety jest mao precyzyjne i charakteryzuje wszelkie projekty ekranów, poczwszy
od odrcznych szkiców, poprzez projekty szkieletowe ekranu (ang. wireframes), a po
gotowe interaktywne prototypy ekranów posiadajce bogat szat graficzn i umoli-
wiajce testowanie ekranu na faszywych danych. Projekty szkieletowe nie uwzgld-
niaj szaty graficznej, a ich celem jest przedstawienie ogólnej funkcjonalnoci poszcze-
gólnych ekranów oraz sposobu prezentacji danych biznesowych.
«screen» «screen»
«screen»
forgotPassword login
assignReviewer
{user.role==admin} + globalMessage: String [0..*] + globalMessage: String [0..*]
forgot_password
+ paper.title: String «input»
+ email: text «submit»
«input»
+ forgotPassword() : String
+ reviewers: select
«submit» + notRegistered() : String
+ getNewPassword() : String
«submit»
+ assign() : String login registration
login_success
get_password_success
«compartment»
logout_success :topMenu
assign_reviewer
assign_success registration
aprove/reject
«screen»
index
+ welcomeMessage: String registration_success «screen»

«screen»
addEditUser
papersList {user.role==admin}
delete + globalMessage: String [0..*]
+ globalMessages: String [0..*] all_papers_list
«compartment» add_user
«screen» :leftMenu
addReview
{user.role==reviewer} edit_user
paper_details + globalMessages: String [0..*]

add_success edit_success
add_success reviewer_papers_list
«screen» add_review
paperDetails
author_papers_list
+ paper.abstract: String
+ paper.acronym: String all_users_list
papers_details «screen»
+ paper.authors: String reviewerPaperList
+ paper.title: String
+ globalMessages: Strin [0..*] «screen»
«submit» usersList {user.role==admin}
+ downloadFile() : void
paper_details + globalMessages: String [0..*]
review_details review_details
«screen»
auhtorPaperList delete
{user.role==author}
«screen»
reviewDetails + globalMessages: String [0..*]
+ review.commentToAdmin {user.role==admin || user.role==reviewer}: String
+ review.commentToAuthor {user.role==author || user.role==reviewer}: String
add_success
+ review.grade: String
edit_paper
review_details
add_new_version add_paper
edit_success
«screen» add_success
addNewVersion «screen»
{user.role==author} addEditPaper
{user.role==author}
«input»
+ paper.file: file
«submit»
+ addNewVersion() : String
Rysunek 2.3. Diagram nawigacji dla aplikacji ISRP
W technice scenopisów generalnie zaleca si stosowanie projektów szkieletowych,

które mog by wytwarzane zarówno odrcznie, z wykorzystaniem narzdzi graficznych
(do popularny jest pakiet MS PowerPoint), jak i za pomoc specjalnych narzdzi
dostpnych w pakietach do modelowania, np. Microsoft Visio Toolkit for Wireframe,
MockupScreens czy Screen Architect for Sparx Enterprise Architect. W rodowisku
Eclipse warto rozway wykorzystanie edytora stron WWW pakietu WTP — utworzo-
ne w ten sposób projekty mog by póniej stosowane podczas implementacji.
Przykad projektu szkieletowego dla ekranu rejestracji uytkownika w systemie ISRP

zosta pokazany na rysunku 2.4. Projekt stanowi rozwinicie modelu ekranu zamiesz-
czonego na rysunku 2.2 zarówno w zakresie specyfikacji kontrolek realizujcych ele-
menty funkcjonalne, jak i rozmieszczenia elementów wizualnych, majcych uatwi
korzystanie ze strony.
Rysunek 2.4. Projekt szkieletowy ekranu rejestracji aplikacji ISRP
2.1.5. Diagram maszyny stanowej

W technice scenopisów diagram maszyny stanowej suy do opisania zachowania ekra-
nu w trakcie realizacji przypadku uycia. Diagram modeluje stan znajdujcego si po
stronie serwera kontrolera ekranu oraz jego zmiany nastpujce w wyniku interakcji
uytkownika z ekranem. Na rysunku 2.5 zamieszczony zosta przykad diagramu ma-
szyny stanowej, ilustrujcy zmiany stanów kontrolera ekranu rejestracji (przedstawio-
nego na rysunku 2.4).
wyjcie po
«ControllerState» klikniciu przycisku
Rejestracja nieaktywna nawigacji
Final
+ entry / dezaktywuj przycisk Zarejestruj
start
zaznaczenie zaznaczenie pola zatwierdzenie

pola wyboru wyboru formularza [walidacja
[pole=true] [pole=false] poprawna]
/dodaj uytkownika
«ControllerState»
Rejestracja aktywna
+ entry / uaktywnij przycisk Zarejestruj

+ exit / waliduj dane formularza zatwierdzenie formularza
[walidacja niepoprawna]
/poka bdy
Rysunek 2.5. Diagram maszyny stanowej dla ekranu rejestracji
Stan pocztkowy reprezentuje stan kontrolera po utworzeniu jego instancji i jest

oznaczony przez strzak wychodzc od elementu start. Kade przejcie (tranzycja)
na diagramie definiuje relacj midzy dwoma stanami kontrolera, wskazujc, e kontro-
ler znajdujcy si w pierwszym stanie wykona pewne akcje i przejdzie do drugiego
stanu, ilekro zajdzie okrelone zdarzenie i bd spenione okrelone warunki. Opis
przejcia skada si z trzech opcjonalnych elementów: wyzwalacza (ang. trigger), dozoru
(ang. guard) i aktywnoci (ang. activity), które opisywane s wedug nastpujcej
skadni: wyzwalacz [dozór] /aktywno. Wyzwalaczem jest zazwyczaj pojedyncze
zdarzenie, które moe spowodowa przejcie i zmian stanu. Dozór okrela warunek
logiczny, jaki musi by speniony, aby przejcie zostao wykonane; warunek ten jest
obliczany w momencie pojawienia si wyzwalacza. Aktywno definiuje operacj
wykonywan w momencie przejcia ze stanu do stanu; nawet jeeli akcja przejcia
jest zoona z wielu akcji elementarnych, jest ona wykonywana niepodzielnie.
Przejcia s oznaczane za pomoc strzaek czcych dwa stany kontrolera i mog by

postrzegane jako zmiany na ekranie, które nie powoduj uaktywnienia regu nawiga-
cji skutkujcych wywietleniem innego ekranu. Podobnie jak w zwykym diagramie
maszyny stanowej, równie tutaj mog wystpowa szczególne przypadki przej ,
których wykonanie nie prowadzi do zmiany danego stanu, tj. przejcia wewntrzne
lub zwrotne. W przypadku przejcia zwrotnego s wykonywane czynnoci wejciowe
oraz wyjciowe danego stanu, w przypadku przej wewntrznych s one pomijane.
Przejcia wewntrzne nie maj odrbnego oznaczenia graficznego, lecz s specyfiko-

wane w obszarze stanu, obok definicji nastpujcych czynnoci:
entry — czynnoci wykonywane w momencie, gdy obiekt przyjmuje dany stan;
do — czynnoci wykonywane nieprzerwanie w czasie, gdy obiekt przebywa
w danym stanie;
exit — czynnoci wykonywane w momencie opuszczenia stanu.
Przejcia wewntrzne lub zwrotne wystpuj w sytuacjach, gdy kompozycja ekranu

zmienia si tylko nieznacznie lub wcale. Stan kocowy (ang. final) wskazuje, e maszyna
stanów jest kompletna, a obiekt kontrolera oraz wszystkie przechowywane w nim zmien-
ne mog zosta usunite.
2.2. Warstwa biznesowa

W rozdziale 1.2.4, „Implementacja MVC w JSF”, przedstawiono ogólny schemat im-
plementacji wzorca MVC w aplikacjach opartych na JSF oraz korzyci pynce z izolo-
wania warstwy biznesowej i prezentacji. W tym punkcie zostan omówione dobre
praktyki projektowe, rozwizania i technologie zwizane z tworzeniem samej warstwy
biznesowej.
2.2.1. Rola i elementy warstwy biznesowej

Pojcie warstwy biznesowej do sugestywnie okrela rol tej warstwy, w której mo-
delowane s obiekty i reguy biznesowe. Stanowi ona zazwyczaj rdze aplikacji i jest
najbardziej rozleg jej warstw, z jednej strony wiadczc usugi dla warstwy pre-
zentacji, z drugiej strony korzystajc z zewntrznych róde danych, takich jak bazy
danych, korporacyjne systemy informacyjne (ang. Enterprise Information Systems —
EIS) czy zewntrzne systemy informatyczne. Separowanie warstwy biznesu od prezen-
tacji uatwia implementacj regu biznesowych i umoliwia uycie obiektów bizneso-
wych w dowolnym rodowisku uruchomieniowym (strona 29 „Korzyci wynikajce
z izolowania warstw widoku i logiki biznesowej”). Ze wzgldu na rozlego warstwy
biznesowej dobrze jest podzieli j na podwarstwy, które s od siebie logicznie od-
dzielone i posiadaj cile zdefiniowane zakresy odpowiedzialnoci, tj. model dzie-
dzinowy, warstw usug i interfejs do warstwy trwaoci danych (patrz rysunek 2.6),
omówione w kolejnych punktach.
Najpopularniejsze podejcia do tworzenia warstwy biznesowej w aplikacjach WWW

oparte s na wykorzystaniu:
zarzdzanych przez kontener komponentów,
zwykych obiektów Javy (ang. Plain Old Java Objects — POJO).
Rysunek 2.6.
Warstwowy model Warstwa prezentacji
architektury
wykorzystany
w aplikacji ISRP
Warstwa biznesowa
Warstwa usugowa (fasady)
Model dziedzinowy (POJO)
Interfejs do warstwy trwaoci (DAO)

Warstwa trwaoci
Programowanie komponentowe jest naturalnym rozszerzeniem programowania zo-

rientowanego obiektowo — nie posiada ono zupenie nowych atrybutów w stosunku
do programowania obiektowego, a jedynie konsekwentnie i w peni wykorzystuje ce-
chy obiektowoci. Komponenty oferuj hermetycznie opakowane, wysokopoziomowe
funkcje realizujce logik biznesow. Zarzdzaniem komponentami zajmuje si kon-
tener, który kontroluje róne aspekty ich ycia, m.in. tworzenie instancji, wprowadza-
nie zalenoci pomidzy nimi czy te zarzdzanie cyklem ich ycia. Kontener po-
zwala na ograniczenie zada stojcych przed komponentami do realizacji jedynie
funkcji biznesowych, dziki czemu s one atwe do zrozumienia, maj czytelne inter-
fejsy i mog by rozproszone w sieci. Programowanie komponentowe boryka si jednak
z wieloma problemami implementacyjnymi, przede wszystkim z du rónorodnoci
protokoów komponentowych i jzyków interfejsów, problemami ze wzajemnym poro-
zumiewaniem si komponentów czy zoonoci infrastruktur rodowisk uruchomienio-
wych. Popularnymi technologiami komponentów s Enterprise Java Beans czy Spring.
Do implementacji warstwy biznesowej w zawartych w ksice przykadach wykorzy-

stywane jest podejcie oparte na klasach POJO. Zalet tego podejcia jest brak zale-
noci od technologii EJB czy Java EE oraz moliwo uycia i testowania jej kodu
bez potrzeby korzystania ze rodowiska uruchomieniowego serwera.
Klasy POJO i komponenty JavaBean

Termin Plain Old Java Objects okrela obiekty zwykych klas Javy, które nie s
ograniczone adnymi specjalnymi restrykcjami i nie musz implementowa adnych
specjalnych zachowa w odrónieniu od np. komponentów EJB 2.x. Klasy POJO nie
powinny dziedziczy po wczeniej predefiniowanych klasach, implementowa predefi-
niowanych interfejsów czy zawiera predefiniowanych adnotacji, jeli te nie s zwizane
z ich podstawow funkcjonalnoci (cho nawet tych wymaga nie naley traktowa
zbyt rygorystycznie). Pojcie POJO zostao wprowadzone przez Martina Fowlera,
Rebecc Parsons i Josha McKenziego w 2000 roku, którzy poprzez wprowadzenie
atrakcyjnie brzmicej nazwy dla zwykych obiektów Javy chcieli wyróni ide wy-
korzystania prostych technik projektowych w programowaniu obiektowym.
Poniewa w aplikacjach korporacyjnych Java EE (J2EE) wymagane s dodatkowe

usugi, takie jak zarzdzanie transakcjami, utrzymywanie bezpieczestwa czy trwao-
ci danych (w alternatywnym podejciu usugi te zapewniaj kontenery EJB), po-
wstay specjalne lekkie szkielety programistyczne (ang. lightweight frameworks), udo-
stpniajce wybrane usugi obiektom POJO. Przykadami lekkich szkieletów s Spring,
Hibernate czy iBatis. Pozytywne dowiadczenia ze stosowania lekkich szkieletów i klas
POJO skoniy równie projektantów technologii EJB do gruntownej przebudowy ich
rozwizania. Poczwszy od wersji EJB 3.0, komponenty EJB s w zasadzie klasami
POJO, które zawieraj adnotacje specyfikujce dodatkowe waciwoci obiektów tych
klas (poza kontenerem EJB adnotacje nie s interpretowane, wic mona stwierdzi ,
e EJB 3.0 to POJO).
Komponenty JavaBean s to napisane w odpowiedniej konwencji klasy POJO, bdce

niezalenymi moduami wielokrotnego uytku w programach Javy. Narzdzia do
tworzenia oprogramowania s w stanie czy i wykorzystywa komponenty JavaBeans
oraz manipulowa nimi dziki przyjciu odpowiednich konwencji w nazywaniu me-
tod, konstrukcji klasy i jej zachowania, a mianowicie:
klasa musi posiada publiczny i bezparametrowy konstruktor;
hermetyzowane waciwoci klasy musz by dostpne do odczytu i modyfikacji
za pomoc specjalnych metod publicznych (tzw. getters & setters), które musz
mie odpowiednio skonstruowane nazwy, zawierajce przedrostki get-, set-
i opcjonalnie is- dla typu boolean, np.: public int getTemperature(), public
void setTemperature(int t), public boolean isFinished() — dla waciwoci
temperature i finished;
klasa powinna by serializowalna (implementowa interfejs Serializable
lub Externalizable);
klasa nie powinna zawiera metod obsugi zdarze.
Przykadowymi komponentami JavaBean s komponenty wspierajce.
2.2.1.1. Model dziedzinowy

Na podstawie analizy przypadków uycia moemy zidentyfikowa podstawowe klasy
konceptualne (pojcia, rzeczy bd obiekty) wystpujce w projektowanym systemie.
Model konceptualny stanowi punkt wyjciowy generowania obiektowego modelu
dziedzinowego oraz modelu relacyjnego (fizycznego). Diagram konceptualny na rysunku
2.7 przedstawia podstawowe pojcia wystpujce w systemie ISRP.
Dokadne odwzorowanie obiektowe koncepcji biznesowych wystpujcych w mode-

lowanym rodowisku zapewnia tzw. model drobnoziarnisty (ang. fine-grained model),
oparty na wykorzystaniu wielu prostych obiektów POJO, reprezentujcych istotne
koncepcje biznesowe. Modele drobnoziarniste znakomicie speniaj swoje funkcje, o ile
nie wystpuje potrzeba rozproszenia obiektów na rónych serwerach. W modelu drobno-
ziarnistym wystpuje mnóstwo wzajemnych odwoa pomidzy obiektami, co stanowi
problem w systemach rozproszonych, gdy zdalne wywoania s do kosztowne.
java.io.Serializable java.io.Serializable
Uytkownik wykonuje Recenzja
mieszka nadsya
Pytanie Odpowied
Kraj Artyku
Rysunek 2.7. Diagram konceptualny systemu ISRP
W takich systemach podejcie komponentowe moe by przydatniejsze, a kontenery

Java EE mog dodatkowo zapewni bezpieczestwo, transakcyjno czy poczenia
w systemach heterogenicznych.
Model dziedzinowy aplikacji ISRP zaimplementowany jest w postaci klas POJO.

Przykad obiektu biznesowego dla koncepcji uytkownika zosta przedstawiony na li-
stingu 2.1.
Listing 2.1. Kod klasy User

package isrp.hibernate.model.businessobject;
import java.util.Date;
public class User implements java.io.Serializable {

private Integer id;
private int countryId;
private String title;
private String firstName;
private String lastName;
private String organization;
private String department;
private String street;
private String zipCode;
private String city;
private String email;
private String password;
private String phone;
private boolean gender;
private Date entryDate;
private Byte role;
public User() { //konstruktor na potrzeby serializacji

}
public User(int countryId, String title, String firstName, String lastName,

String organization, String department, String street,
String zipCode, String city, String email, String password,
String phone, boolean gender, Date entryDate, Byte role) {
this.countryId = countryId;
this.title = title;
this.firstName = firstName;
this.lastName = lastName;
this.organization = organization;
this.department = department;
this.street = street;
this.zipCode = zipCode;
this.city = city;
this.email = email;
this.password = password;
this.phone = phone;
this.gender = gender;
this.entryDate = entryDate;
this.role = role;
}
public Integer getId() {return this.id;}
public void setId(Integer id) {this.id = id;}
/* ...Pozostae gettery i settery ...*/

}
Podejcie polegajce na wyprowadzeniu implementacji logiki biznesowej poza mo-

del dziedzinowy i obiekty reprezentujce dane okrelane jest w literaturze mianem
anemicznego modelu dziedzinowego. Wprowadzi je Martin Fowler, który traktuje
takie rozwizanie jako antywzorzec. Najwaniejszym zarzutem, jaki stawia Fowler
takiemu modelowi, jest naruszenie zasad OOP w zakresie enkapsulacji i hermety-
zacji kodu — przetwarzaniem stanu obiektów dziedzinowych czy te ich walidacj
zajmuj si zewntrzne klasy. Inne istotne mankamenty to zmniejszenie czytelnoci
kodu oraz zwikszenie moliwoci wystpowania duplikacji w kodzie. Mimo tych wad
(wyjanionych dokadnie w artykule pod adresem http://www.martinfowler.com/bliki/
AnemicDomainModel.html) rozwizanie to jest czsto i chtnie stosowane, zwaszcza
gdy obiektowy model dziedzinowy jest generowany automatycznie, za pomoc na-
rzdzi ORM, na podstawie istniejcego wczeniej modelu fizycznego.
2.2.1.2. Warstwa usugowa

Bardzo wane na etapie projektowania jest rozrónienie dwóch aspektów funkcjonal-
noci systemu wystpujcych w warstwie biznesowej: modelu dziedzinowego i logiki
biznesowej. Model dziedzinowy reprezentuje koncepcje biznesowe i ich zachowanie,
podczas gdy logika biznesowa reprezentuje procesy i przepywy sterowania odpowia-
dajce scenariuszom przypadków uycia. Oddzielenie logiki biznesowej od modelu
dziedzinowego jest moliwe poprzez wprowadzenie warstwy usugowej (ang. service
layer) odpowiedzialnej za:
zdefiniowanie uproszczonego interfejsu dla klientów modelu dziedzinowego,
implementacj zoonych obiektów usug zdefiniowanych przez wyej
wymieniony interfejs.
Obiekty usug mog zapewnia fasady dla modelu dziedzinowego (strona 83 „Wzo-
rzec fasady”) oraz implementowa procesy biznesowe.
Na przykad na diagramie przypadków uycia systemu ISRP wystpuje przypadek

Przypisz recenzenta do pracy, który reprezentuje zoony proces biznesowy. W ra-
mach tego procesu zachodzi nastpujca sekwencja czynnoci: redaktor z uprawnie-
niami administratora wybiera z listy recenzenta, do którego automatycznie wysyane
jest zawiadomienie (poczt elektroniczn — SMTP), i zapisywany jest stan procesu
w bazie danych. Zamiast wywoywa wiele metod dla obiektów modelu dziedzinowego
w warstwie prezentacji, moemy wywoa jedn metod void assignReviewer(Paper
paper,int reviewerId), zdefiniowan w fasadzie PaperService, której kod zosta za-
mieszczony na listingu 2.2. Zgodnie z dobr praktyk programowania obiektowego,
polegajc na przedkadaniu interfejsów nad implementacje, wszystkie metody wy-
magane dla realizacji procesów biznesowych zwizanych z przetwarzaniem artykuów
konferencyjnych s okrelone w interfejsie PaperService.
Listing 2.2. Kod ródowy interfejsu PaperService

package isrp.model.service;
import java.util.List;
import org.apache.myfaces.custom.fileupload.UploadedFile;
import isrp.hibernate.model.businessobject.Paper;
import isrp.hibernate.model.businessobject.User;
import isrp.hibernate.model.util.email.EmailConfiguration;
public interface PaperService {
boolean addPaperNewVersion(Paper paper,User author,UploadedFile

úploadedFile,String uploadPath,EmailConfiguration emailConfiguration);
void update(Paper paper);
void assignReviewer(Paper paper,int reviewerId,EmailConfiguration
émailConfiguration);
boolean addPaper(Paper paper,User author,UploadedFile uploadedFile,String
úploadPath,EmailConfiguration emailConfiguration);
Paper findById(int id);
void delete(Paper paper);
void approvePaper(Paper paper,EmailConfiguration emailConfiguration);
void rejectPaper(Paper paper,EmailConfiguration emailConfiguration);
List<Paper> getReviewerPapers(int reviewerId, String sortColumn);
List<Paper> getAuthorPapers(int userId, String sortColumn);
List<Paper> getAllPapers(String sortColumn);
List<Paper> getAllPapers(String sortColumn,Integer userId, Integer role);
}
Implementacja metod interfejsu PaperService znajduje si w klasie PaperServiceImpl.

Poniewa rozmiar caego kodu klasy jest obszerny, na listingu 2.3 zamieszczony zo-
sta wycznie jego fragment, zawierajcy deklaracj klasy oraz implementacj metody
odpowiedzialnej za przypisanie recenzenta i wysanie powiadomienia poczt elektro-
niczn.
Listing 2.3. Implementacja interfejsu PaperService

public class PaperServiceImpl implements PaperService{
public PaperServiceImpl() {}// bezargumentowy konstruktor
public void assignReviewer(Paper paper, int reviewerId,

EmailConfiguration emailConfiguration) {
/* pobranie obiektów dostpowych do tabel — patrz listing 2.11*/

PaperDao pDao = DaoFactory.getInstance().getPaperDao();
UserDao uDao = DaoFactory.getInstance().getUserDao();
pDao.saveOrUpdate(paper);
User author=(User) uDao.findById(paper.getAuthorId());//pobranie obiektu autora
User reviewer=(User) uDao.findById(reviewerId);//pobranie obiektu recenzenta
/* wysanie potwierdzenia poczt elektroniczn*/
EmailSender eSender = new EmailSender(emailConfiguration);
eSender.sendEMail(EmailMessagesUtil
.assignReviewerMessageToReviewer(reviewer, paper));
}
/* ... implementacje pozostaych metod interfejsu PaperService*/
}
Wzorzec fasady
Wzorzec fasady jest jednym z podstawowych i jednoczenie najprostszych struktural-
nych wzorców projektowych. Zapewnia on dostp do zoonych systemów, prezentujc
uproszczony lub uporzdkowany interfejs programistyczny. Wzorzec fasady pozwala:
ukry zoono tworzonego systemu poprzez dostarczenie prostego interfejsu API,
uproci interfejs istniejcego systemu poprzez stworzenie nakadki, która
dostarcza nowy interfejs API.
Obiekt fasady jest prostym obiektem poredniczcym pomidzy obiektem klasy klienta
dajcym okrelonej funkcjonalnoci a klasami dostarczajcymi elementów do uzy-
skania tej funkcjonalnoci.
2.2.1.3. Lokalizatory usug

Usugi biznesowe powinny by atwo dostpne dla wszelkiego typu klientów, nieza-
lenie od tego, czy s one klientami lokalnymi, czy te zdalnymi. Gdy w warstwie
biznesowej wystpuje wiele fasad, korzystanie z usug biznesowych moemy uatwi
poprzez zastosowanie uproszczonej wersji wzorca lokalizatora usug (czciowo opi-
sanego w rozdziale 1., w ramce „Wzorzec delegata biznesowego”). Obiekt lokalizato-
ra tworzy jeden punkt dostpowy do kodu warstwy biznesowej, jednoczenie zmniej-
szajc zaleno klienta od implementacji mechanizmów wyszukiwania usug.
Zazwyczaj lokalizator jest implementowany jako pojedynczy obiekt (singleton), chyba
e stosowany jest w rodowisku rozproszonym.
Na przykad w systemie ISRP istniej zdefiniowane odrbne fasady dla usug zwizanych
z przetwarzaniem artykuów, uytkowników, recenzentów, formularzy z pytaniami
oraz danych sownikowych. Przedstawiony na listingu 2.4 interfejs ServiceLocator
zawiera deklaracje metod, które udostpniaj obiekty implementujce interfejsy tych
fasad. Operowanie na interfejsach pozwala na uniezalenienie si od jednej konkretnej
implementacji zestawu fasad, dziki czemu atwo moemy dostarczy implementacje
zoptymalizowane pod ktem wydajnoci czy bezpieczestwa.
Listing 2.4. Kod ródowy interfejsu lokalizatora usug

package isrp.model.service.factory;
import isrp.model.service.CountryService;
import isrp.model.service.PaperService;
import isrp.model.service.QuestionService;
import isrp.model.service.ReviewService;
import isrp.model.service.UserService;
public interface ServiceLocator {

PaperService getPaperService();
UserService getUserService();
ReviewService getReviewService();
CountryService getCountryService();
QuestionService getQuestionService();
}
Na listingu 2.5 przedstawiono kod klasy lokalizatora ServiceLocatorImpl, definiujcego

metody dostpowe zwracajce obiekty fasad. Aby tak prosty lokalizator wykonywa
swoje zadanie, naley waciwie zainicjowa i przechowa jego instancj w kontenerze,
co jest opisane w nastpnym punkcie.
Listing 2.5. Kod ródowy lokalizatora usug ServiceLocatorImpl

package isrp.model.service.factory;
import org.apache.commons.logging.*;
import isrp.model.service.*;
import isrp.model.service.impl.*;
public class ServiceLocatorImpl implements ServiceLocator{
private PaperService paperService;

private UserService userService;
private ReviewService reviewService;
private CountryService countryService;
private QuestionService questionService;
private Log log = LogFactory.getLog(this.getClass());
public ServiceLocatorImpl() {
this.paperService = new PaperServiceImpl();
this.userService = new UserServiceImpl();
this.reviewService = new ReviewServiceImpl();
this.countryService = new CountryServiceImpl();
this.questionService = new QuestionServiceImpl();
this.log.info("Service locator bean is initialized");
}
public PaperService getPaperService() {return paperService;}
public UserService getUserService() {return userService;}
public ReviewService getReviewService() {return reviewService;}
public CountryService getCountryService() {return countryService;}
public QuestionService getQuestionService() {return questionService;}
}
2.2.1.4. Integracja warstwy usugowej z warstw prezentacji JSF

Wygodnym sposobem integracji warstwy usugowej z warstw prezentacji aplikacji
JSF jest wykorzystanie mechanizmu komponentów zarzdzanych. Na przykad obiekt
lokalizatora usug moe zosta zarejestrowany w aplikacji jako komponent zarzdzany
o zasigu aplikacji. Bdzie on wówczas automatycznie tworzony w momencie pierw-
szego odwoania si do niego, a nastpnie przechowywany w kontekcie aplikacji JSF
a do koca jej dziaania.
Deklaratywny sposób rejestracji obiektu lokalizatora w pliku faces-config.xml zosta

zaprezentowany na listingu 2.6. Pokazane na przykadzie rozwizanie umoliwia do-
stp do obiektu lokalizatora poprzez wykorzystanie jego identyfikatora — service
´LocatorImpl lub waciwoci komponentu uytkowego utilBean (opis komponentów
zarzdzanych znajduje si w rozdziale 3.). W omawianym przykadzie lokalizatorem
jest obiekt zaprezentowanej na listingu 2.5 klasy ServiceLocatorImpl, ale dziki sto-
sowaniu interfejsów fasad moe on zosta atwo zamieniony na inny obiekt bdcy
lokalizatorem, do czego wystarczy zmiana wartoci elementu <managed-bean-class>.
Moe si to okaza przydatne, np. gdy bdziemy chcieli zapewni buforowanie prze-
syanych danych czy zdalny dostp do usug.
Listing 2.6. Integracja warstwy usugowej w pliku faces-config.xml

<managed-bean>
<description> Komponent lokalizatora </description>
<managed-bean-name>serviceLocatorImpl</managed-bean-name>
<managed-bean-class>isrp.model.service.factory.ServiceLocatorImpl</managed-bean-class>
<managed-bean-scope>application</managed-bean-scope>
</managed-bean>
<managed-bean>
<managed-bean-name>utilBean</managed-bean-name>
<managed-bean-class>isrp.viewbeans.UtilBean</managed-bean-class>
<managed-bean-scope>application</managed-bean-scope>
<managed-property>
<property-name>serviceLocator</property-name>
<value>#{serviceLocatorImpl}</value>
</managed-property>

</managed-bean>
2.2.2. Interfejs do warstwy trwaoci danych

Cho wspóczesne aplikacje WWW mog korzysta z wielu moliwoci w zakresie
utrwalania danych, to wci najpopularniejsz z nich jest stosowanie relacyjnych baz da-
nych. Interfejs do warstwy trwaoci powinien cakowicie oddziela szczegóy techno-
logii relacyjnych od warstwy biznesu, jednoczenie zapewniajc nastpujce operacje:
funkcje CRUD, tj. ang. Create, Retrieve, Update, Delete (utwórz, odczytaj,
modyfikuj i usu obiekty w pamici trwaej),
tworzenie i uruchamianie zapyta do bazy danych,
zarzdzanie poczeniami, transakcjami, buforowaniem i wydajnoci.
Korzystajc z relacyjnych baz danych, naley zapewni odwzorowania obiektów Javy

na tabele, kolumny i rekordy, podobnie jak mapowanie wzajemnych relacji pomidzy
obiektami na powizania tabel i rekordów. W tym celu mona zastosowa :
interfejs JDBC API,
komponenty encji dostpne w technologii Java Persistence API,
technologie odwzorowa obiektowo-relacyjnych (ORM).
W zasadzie dwa ostatnie rozwizania s do podobne — JPA byo wzorowane na

szkieletach ORM Hibernate i TopLink. Technologie ORM pozwalaj zarówno utrwala
obiekty POJO w bazie danych, jak i generowa model dziedzinowy na podstawie
schematu bazy danych (tzw. reverse engineering). Dziki temu stanowi wygodne
rozwizanie, które moemy wykorzysta niezalenie od scenariusza, wedug jakiego
wytwarzana jest warstwa trwaoci, a mianowicie gdy:
istnieje kod Javy i naley zapewni przechowywanie obiektów Javy w bazie
danych,
istnieje zaprojektowana (lub odziedziczona z innego systemu) baza danych
i naley napisa kod aplikacji. Model dziedzinowy w Javie jest dopasowywany
do schematu bazy danych,
istnieje zarówno baza danych, jak i cz kodu Javy, które naley powiza .
W dalszych punktach przyblione zostan najwaniejsze informacje dotyczce wyko-

rzystania biblioteki Hibernate w celu zapewnienia dostpu do danych.
2.2.2.1. Interfejs warstwy danych oparty na Hibernate

Hibernate jest darmowym szkieletem programistycznym, sucym do realizacji war-
stwy dostpu do danych i zapewniajcym translacj danych pomidzy relacyjn baz
danych a wiatem obiektowym. Uycie Hibernate powoduje, e z punktu widzenia
programisty baza danych zawiera zwyke obiekty Javy (POJO). Hibernate zapewnia
poczenia z baz danych i obsug podstawowych operacji na nich z uwzgldnieniem
przenonoci midzy rónymi dialektami SQL.
Zasada dziaania Hibernate opiera si na zastosowaniu plików konfiguracyjnych defi-

niowanych w jzyku XML oraz uyciu mechanizmu refleksji do pobierania obiektów
i waciwoci klas. Plik konfiguracyjny o nazwie hibernate.cfg.xml zawiera globalne
ustawienia parametrów szkieletu oraz poczenia do bazy danych. Przykad pliku kon-
figuracyjnego dla aplikacji ISRP zosta przedstawiony na listingu 2.7. Znaczenie po-
szczególnych elementów opisane jest w komentarzach do kodu.
Listing 2.7. Plik konfiguracji Hibernate

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-configuration PUBLIC
"-//Hibernate/Hibernate Configuration DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
<session-factory>


<property name="hibernate.connection.driver_class">com.mysql.
´jdbc.Driver</property>
<property name="hibernate.connection.url">jdbc:mysql:
´//localhost/isrp</property>
<property name="hibernate.connection.useUnicode">yes</property>
<property name="hibernate.connection.characterEncoding">UTF-8</property>
<property name="hibernate.connection.username">root</property>
<property name="hibernate.dialect">org.hibernate.dialect.
´MySQLDialect</property>
<property name="current_session_context_class">thread</property>

<property name="hibernate.show_sql">true</property>

<mapping resource="isrp/hibernate/model/businessobject/Answer.hbm.xml" />
<mapping resource="isrp/hibernate/model/businessobject/User.hbm.xml" />
<mapping resource="isrp/hibernate/model/businessobject/Country.hbm.xml" />
<mapping resource="isrp/hibernate/model/businessobject/Paper.hbm.xml" />
<mapping resource="isrp/hibernate/model/businessobject/Question.hbm.xml" />
<mapping resource="isrp/hibernate/model/businessobject/Review.hbm.xml" />
<mapping resource="isrp/hibernate/model/businessobject/
Ánswersquestions.hbm.xml" />
</session-factory>
</hibernate-configuration>
Pliki mapowa Hibernate odpowiadaj za translacj danych znajdujcych si w tabeli

na obiekty Javy i odwrotnie. Oznaczane s przyrostkiem .hbm.xml, gdzie pierwszy ele-
ment przyrostka jest skrótem od wyraenia „HiBernate Mapping”. Poniej zamieszczono
fragment pliku mapowania User.hbm.xml. Diagram penego mapowania przykado-
wej klasy User do tabeli user, wygenerowany przy uyciu narzdzia HibernateTools,
zaprezentowano na rysunku 2.8.
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping>
<class name="isrp.hibernate.model.businessobject.User" table="user" catalog="isrp">
<id name="id" type="java.lang.Integer">
<column name="id" />
<generator class="identity" />
</id>
<property name="countryId" type="int">
<column name="countryId" not-null="true" />
</property>
</class>
</hibernate-mapping>
Instalacja Hibernate sprowadza si do pobrania i rozpakowania pakietów instalacyjnych,

dostpnych na stronie http://sourceforge.net/projects/hibernate/files/hibernate3/. Po
rozpakowaniu pliki bibliotek powinny zosta umieszczone w ciece przeszukiwania
klas projektu. Najwaniejsze klasy Hibernate znajduj si w pliku hibernate3.jar, a klasy
pomocnicze w plikach bibliotek: commons-collections.jar, commons-logging.jar,
dom4j.jar, hsqldb.jar, jta.jar, c3p0.jar, ehcache.jar, cglib.jar i antlr.jar.
Rysunek 2.8. Przykadowy diagram mapowania wygenerowany w HibernateTools
Hibernate Tools
Wsparcie korzystania z biblioteki Hibernate w rodowisku Eclipse zapewnia wtyczka
programistyczna Hibernate Tools, udostpniana za darmo przez Red Hat Inc. Hibernate
Tools dostarcza zestaw widoków i kreatorów zawierajcy m.in.:
kreator dla realizacji procesu inynierii wstecznej (ang. reverse engineering),
umoliwiajcy wygenerowanie modelu obiektowego na podstawie tabel i kolumn
istniejcej bazy danych,
kreator konfiguracji hibernate.cfg.xml,
w peni funkcjonalny edytor dla jzyka Hibernate HQL,
okno komend jzyka SQL,
podpowiadanie skadni SQL,
w peni funkcjonalny edytor plików odwzorowa .hbm.xml.
Wtyczk Hibernate Tools moemy zainstalowa wedug opisu w ramce „Wtyczki pro-
gramistyczne w Eclipse”. Wówczas w polu Work with menedera instalacji wpisuje-
my nastpujcy adres:
http://download.jboss.org/jbosstools/updates/stable.
2.2.2.2. Obiekty dostpu do danych DAO

Obiekty implementujce interfejs do warstwy trwaoci s zazwyczaj okrelane jako
obiekty dostpu do danych (ang. Data Access Objects — DAO). Dobr praktyk pro-
jektow wynikajc ze stosowania tego wzorca jest tworzenie pojedynczego obiektu
DAO dla kadej utrwalanej klasy. Generalnie do najwaniejszych zada DAO nale
tworzenie (pobieranie) sesji Hibernate oraz zapisywanie (pobieranie) obiektów.
Poniewa pewne operacje (zapis, odczyt czy wyszukiwanie) powtarzaj si we wszystkich
DAO, celem uniknicia powielania kodu moemy zdefiniowa wspólny interfejs oraz
klas abstrakcyjn zawierajc definicj powtarzajcych si dla rónych typów operacji.
Generyczny interfejs zosta zaprezentowany na listingu 2.8, a implementujca jego
metody klasa abstrakcyjna GenericDao na listingu 2.9.
Listing 2.8. Interfejs definiujcy podstawowe operacje dla DAO

package isrp.hibernate.model.dao;
public interface GenericDaoInterface {

public abstract Object findById(int id);//wyszukiwanie po id
public abstract void save(Object object);//zapisywanie nowego obiektu
public abstract void saveOrUpdate(Object object);//zapisywanie lub modyfikowanie
//obiektu, jeli istnieje
public abstract void delete(Object object);//usuwanie obiektu
public abstract List findAll();//wyszukiwanie wszystkich obiektów
}
Listing 2.9. Implementacje podstawowych operacji dostpnych w DAO

import isrp.hibernate.model.util.HibernateUtil;
import org.hibernate.SessionFactory;
import org.hibernate.Session;
import org.hibernate.Criteria;
public abstract class GenericDao implements GenericDaoInterface {

protected Class persistedClass;
protected Session session;
public GenericDao(Class persistedClass) {

/* pobranie sesji Hibernate z obiektu klasy uytkowej, zaprezentowanej na listingu 2.14*/
SessionFactory factory = HibernateUtil.getSessionFactory();
this.session = factory.getCurrentSession();
this.persistedClass = persistedClass;
}
public Object findById(int id) {
Object object = (Object) session.get(persistedClass, id);
return object;
}
public void save(Object object) {
session.save(object);
}
public void saveOrUpdate(Object object) {
session.saveOrUpdate(object);
}
public void delete(Object object) {
session.delete(object);
}
public List findAll() {
Criteria criteria = session.createCriteria(persistedClass);
return criteria.list();
}
}
Zastosowanie klasy abstrakcyjnej GenericDao pozwala na znaczne uproszczenie im-

plementacji konkretnych obiektów DAO. Na listingu 2.10 znajduje si kod ródowy
klasy UserDao, w którym zaimplementowane zostay wycznie operacje specyficzne
dla utrwalania obiektów User.
Listing 2.10. Kod ródowy klasy UserDao

import org.hibernate.Query;
import org.hibernate.criterion.Order;
import org.hibernate.criterion.Restrictions;
import isrp.hibernate.model.businessobject.User;
import isrp.hibernate.model.util.Md5HashCode;
public class UserDao extends GenericDao {
public UserDao() {
super(User.class);//
}
public String getAdministratorEmail(){
User user = null;
Query query = session.createQuery("FROM User where role=?")
.setByte(0, new Byte("1"));
user = (User) query.uniqueResult();
return user.getEmail();
}
public List getReviewers(){
return session.createCriteria(persistedClass)
.add(Restrictions.eq("role", new Byte("3")))
.list();
}
public User authenticate(String email, String password) {
password = Md5HashCode.getMd5HashCode(password);
return (User) session.createCriteria(persistedClass)
.add(Restrictions.eq("email", email))
.add(Restrictions.eq("password", password))
.uniqueResult();
}
public User checkIfEmailExistInDB(String email) {
Query query = session.createQuery("FROM User where email=?")
.setString(0, email);
return (User) query.uniqueResult();
}
public List<User> getUsers(String sortColumn){
if (sortColumn==null){
sortColumn="firstName";
}
return (List<User>) session.createCriteria(persistedClass)
.addOrder(Order.asc(sortColumn))
.list();
}
}
Automatyczne generowanie DAO w Hibernate Tools

Hibernate umoliwia automatyczne generowanie obiektów DAO z wykorzystaniem
narzdzia Ant (opis znajduje si w dokumentacji Hibernate) bd wymienionej ju w tym
rozdziale wtyczki Hibernate Tools. Korzystajc z wtyczki Hibernate Tools, w rodo-
wisku Eclipse w grupie menu Run pojawi si nowa opcja — Hibernate Code Generation
Configurations, bdca konfiguracj uruchomieniow automatycznego generowania
kodu przy uyciu Hibernate. Wybór tej opcji powoduje wywietlenie okna kreatora
Create, manage and run configurations, które w zakadce Exporters pozwala ustawi
opcj automatycznego generowania kodu ródowego klas DAO (opcja DAO code).
Automatycznie generowane w ten sposób klasy bd jednak opiera si na wykorzystaniu
interfejsu JNDI i obiektów klasy javax.naming.InitialContext. Nie jest to proble-
mem w przypadku serwerów aplikacji, ale przy korzystaniu z prostych kontenerów
serwletów, takich jak Tomcat, stanowi to utrudnienie, gdy naley samodzielnie za-
pewni kontekst pocztkowy. Tomcat wprawdzie dostarcza wasny obiekt kontekstowy
JNDI, ale nie mona go modyfikowa z poziomu kodu aplikacji (jest tylko do odczy-
tu), co powoduje, e nie moe on by wykorzystany przez Hibernate. Rozwizaniem
tego problemu jest uycie biblioteki Sun FS Context, dostpnej w pliku fscontext.jar,
która umoliwia przechowanie kontekstu aplikacji w postaci plików.
2.2.2.3. Fabrykowanie obiektów DAO

Analogicznie do problemu lokalizacji fasad w warstwie usugowej w przypadku uy-
cia DAO równie istotnym problemem jest zapewnienie atwej lokalizacji obiektów
poprzez centralizacj dostpu. W przypadku interfejsu do warstwy trwaoci centrali-
zacja ma za zadanie uatwienie tworzenia obiektów DAO oraz zamiany ich imple-
mentacji. Dostarczenie interfejsu do tworzenia rónych obiektów implementujcych
wspólny interfejs bez specyfikowania ich konkretnych klas zapewnia wzorzec pro-
jektowy fabryki abstrakcyjnej (ang. abstract factory). Umoliwia on jednemu obiektowi
tworzenie rónych, powizanych ze sob reprezentacji podobiektów, okrelajc ich
typy podczas dziaania programu.
Przykadowa fabryka abstrakcyjna dla obiektów DAO uyta w aplikacji ISRP zapre-
zentowana zostaa na listingu 2.11, a jej implementacja na listingu 2.12. Przykady
wykorzystania fabryki obiektów do tworzenia DAO w warstwie usugowej zaprezen-
towano na listingu 2.13.
Listing 2.11. Fabryka abstrakcyjna obiektów DAO

package isrp.hibernate.model.dao.factory;
import isrp.hibernate.model.dao.*;
public abstract class DaoFactory {

private static DaoFactory instance = new HibernateDaoFactory();
public static DaoFactory getInstance() {

return instance;
}
public abstract UserDao getUserDao();

public abstract CountryDao getCountryDao();
public abstract PaperDao getPaperDao();
public abstract QuestionDao getQuestionDao();
public abstract ReviewDao getReviewDao();
public abstract AnswersquestionsDao getAnswersquestionsDao();
}
Listing 2.13. Implementacja fabryki obiektów DAO

package isrp.hibernate.model.dao.factory;
import isrp.hibernate.model.dao.*;
public class HibernateDaoFactory extends DaoFactory {
public UserDao getUserDao() {return new UserDao();}

public CountryDao getCountryDao() {return new CountryDao();}
public PaperDao getPaperDao() {return new PaperDao();}
public QuestionDao getQuestionDao() {return new QuestionDao();}
public ReviewDao getReviewDao() {return new ReviewDao();}
public AnswersquestionsDao getAnswersquestionsDao() {return new
ÁnswersquestionsDao();}
}
Listing 2.13. Kod filtru umoliwiajcego automatyczne zarzdzanie sesj Hibernate

package isrp.filters;
import isrp.util.HibernateUtil;
import java.io.IOException;
import javax.servlet.*;
import org.apache.commons.logging.*;
import org.hibernate.*;
public class HibernateSessionFilter implements Filter {
private SessionFactory factory = null;

private static final Log log = LogFactory.getLog(HibernateSessionFilter.class);
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
Session session = factory.getCurrentSession();
try {
session.beginTransaction();
log.debug("<< HIBERNATE START");
chain.doFilter(request, response);
log.debug(">> HIBERNATE END");
session.getTransaction().commit();
} catch (Throwable e) {
try {
if (session.getTransaction().isActive()) {
session.getTransaction().rollback();
}
} catch (HibernateException e1) {
log.error("Niemoliwe wykonanie operacji rollback", e1);
e1.printStackTrace();
}
throw new ServletException(e);
}
}
public void destroy() {}
public void init(FilterConfig filterConfig) throws ServletException{

factory = HibernateUtil.getSessionFactory();
if (filterConfig == null) {
log.error("HibernateSessionFilter: Nie zainicjowano filtru");
throw new ServletException();
}
}
}
2.2.2.4. Zarzdzanie sesj Hibernate w warstwie widoku

W celu zapewnienia zarzdzania poczeniem z baz danych (tzw. sesj Hibernate)
moemy wykorzysta wzorzec Open Session in View (OSIV), którego idea opiera si
na zaoeniu, e zawsze do wygenerowania odpowiedzi HTTP niezbdne s informacje
przechowywane w bazie danych. Sesja Hibernate otwierana jest po pojawieniu si -
dania HTTP i jest dostpna przez cay proces generowania strony widoku. Wprowadzone
zmiany do bazy zatwierdzane s dopiero po realizacji caego dania, tj. wygenero-
waniu dokumentu odpowiedzi HTTP. Nie jest to jedyna moliwa do zastosowania tutaj
strategia; warto wspomnie o rozwizaniach polegajcych na wprowadzaniu zmian do
bazy danych w trybie automatycznego zatwierdzania transakcji (autocommit) czy te
inicjowaniu sesji i pobieraniu danych niezbdnych do generowania warstwy widoku
jeszcze przed przekazaniem sterowania do niej. Strategie zarzdzania sesj Hibernate
opisane s wyczerpujco w ksikach POJOs in Action. Developing Enterprise Appli-
cations with Lightweight Frameworks2 oraz Java Persistence with Hibernate3. Wzorzec
OSIV pozwala na realizacj wielu operacji w trakcie jednej sesji z Hibernate. Na listingu
2.13 przedstawiono uyty w aplikacji ISRP filtr implementujcy wzorzec OSIV. Filtr
przechwytuje wszystkie dania pynce do aplikacji i dla kadego z nich rozpoczyna
now transakcj, w której realizowane s wszystkie operacje na bazie danych, reali-
zowane w trakcie przetwarzania dania HTTP. Transakcja jest zatwierdzana dopiero
po zakoczeniu przetwarzania dania. Filtr zawiera obsug wszelkich wyjtków i b-
dów, które mog wystpi podczas przetwarzania dania. Jeli istnieje aktywna sesja
Hibernate, to po wystpieniu bdów lub wyjtków zmiany w bazie danych s wyco-
fywane (rollback). W kodzie do pobrania biecej sesji Hibernate uyto klasy po-
mocniczej HibernateUtil, zaprezentowanej na listingu 2.14. Interakcje wystpujce
pomidzy elementami implementacji wzorca OSIV przedstawione zostay na rysunku 2.9.
Rejestracja filtru w pliku web.xml w najprostszym schemacie bdzie mie nastpujc

posta :
2
Chris Richardson, POJOs in Action. Developing Enterprise Applications with Lightweight Frameworks,
Manning 2006.
3
Christian Bauer, Gavin King, Java Persistence with Hibernate, Manning 2006.
<filter>
<filter-name>HibernateSessionFilter</filter-name>
<filter-class>isrp.filters.HibernateSessionFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>HibernateSessionFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Jak atwo zauway , w powyszym kodzie wykonano mapowanie filtru na wszystkie

zasoby URL, co jest rozwizaniem wysoce niewydajnym — sesja Hibernate jest two-
rzona zawsze, równie dla tych da HTTP, których przetwarzanie nie wymaga po-
czenia do bazy danych. Uytkownik w tym miejscu w zalenoci od potrzeb moe
zmieni mapowanie na wybrane dania lub filtracj da obsugiwanych tylko
przez wybrany serwlet (np. poprzez wstawienie w miejsce znaczników <url-pattern>
znacznika <servlet-name>Faces Servlet</servlet-name> do obsugi da przez apli-
kacj JSF).
Listing 2.14. Kod klasy uytkowej HibernateUtil

package isrp.hibernate.model.util;
import org.hibernate.cfg.AnnotationConfiguration;
import org.hibernate.SessionFactory;
public class HibernateUtil {

private static final SessionFactory sessionFactory;
private static final Log log = LogFactory.getLog(HibernateUtil.class);
static {
try {// Tworzy SessionFactory na podstawie konfiguracji w pliku hibernate.cfg.xml
sessionFactory = new AnnotationConfiguration()
.configure().buildSessionFactory();
} catch (Throwable ex) {
log.error("Nie mona pobra sesji Hibernate " + ex);
throw new ExceptionInInitializerError(ex);
}
}
public static SessionFactory getSessionFactory() {
return sessionFactory;
}
}
Organizujc kod aplikacji, naley pamita, e HibernateSessionFilter jest elemen-

tem warstwy widoku aplikacji WWW, podczas gdy klasa HibernateUtil zapewnia
dostp do warstwy trwaoci.
Klient Kontener Web Hibernate Filter HibernateUtil FacesServlet
JSF Request()
doFilter()
getSessionFactory()
beginTransaction()
service()
commit()
Rysunek 2.9. Diagram sekwencji wzorca OSIV dla aplikacji JSF
2.3. Organizacja kodu aplikacji

w Eclipse
Kod aplikacji WWW opartych na technologii Java EE zazwyczaj jest wytwarzany
w postaci wielu moduów, rozwijanych niezalenie przez róne zespoy projektowe.
Rozproszenie kodu aplikacji w wielu projektach uatwia m.in.:
zarzdzanie kodem ródowym i plikami zasobów,
podzia pracy w zespoach,
zautomatyzowanie procesu wytwarzania i testowania aplikacji.
W dalszej czci rozdziau znajduje si opis rozwiza, jakie zapewnia Eclipse WTP
w zakresie organizacji kodu ródowego oraz integracji i wdraania skompilowanych
moduów aplikacji na serwerze.
2.3.1. Projekty i moduy Java EE w Eclipse

Zanim zajmiemy si planowaniem rozmieszczenia kodu aplikacji ISRP, warto przybliy
podstawowe koncepcje zwizane z wytwarzaniem i wdraaniem aplikacji Java EE w ro-
dowisku Eclipse Web Tools Platform, a mianowicie projekt i modu aplikacji.
Wszystkie pliki ródowe oraz inne zasoby aplikacji bd biblioteki musz by umiesz-
czone w projekcie skadajcym si z jednego lub wielu zagniedonych katalogów.
Projekt stanowi podstawow jednostk organizacyjn kodu aplikacji i jest zapisywany
w przestrzeni projektów (ang. workspace). Projekt opisywany jest za pomoc meta-
danych, które zawieraj pomocnicze informacje o wymaganych zasobach zewntrz-
nych, sposobie kompilacji czy rodowisku uruchomieniowym. Logiczna struktura
prezentowanych w oknie Project Explorer katalogów i zasobów projektu jest zopty-
malizowana pod ktem uatwienia pracy deweloperom.
Modu aplikacji (ang. module) reprezentuje gotowy do wdroenia na serwerze apli-

kacji kod wynikowy projektu (powstay po jego skompilowaniu), który moe by re-
prezentowany przy uyciu plików archiwalnych, np. WAR lub JAR. Moduy Java EE
posiadaj okrelon przez specyfikacj Java EE fizyczn struktur katalogów oraz
plików. Moduy mog by wdraane w kontenerze Java EE zarówno w postaci spa-
kowanych plików archiwum, jak te rozpakowanych struktur katalogów. Eclipse
WTP wspiera wytwarzanie i wdraanie nastpujcych moduów Java EE (w nawiasach
podano typy archiwum oraz nazwy odpowiadajcych im projektów Eclipse po mylniku):
Enterprise application (EAR) — Enterprise application Project,
Enterprise application client (JAR) — Application Client Project,
Enterprise JavaBean (JAR) — EJB Project,
Web application (WAR) — Dynamic Web Project,
Resource adapter for JCA (RAR) — Connector Project,
Utility module (JAR) — Utility Project.
Pierwszych pi wymienionych typów moduów jest okrelonych w specyfikacji Java

EE, natomiast ostatni typ zosta wprowadzony przez rodowisko Eclipse i stanowi
modu uytkowy (Utility module) ogólnego przeznaczenia, umoliwiajcy podzia
kodu aplikacji na oddzielne projekty. Kady projekt WTP moe generowa tylko jeden
modu aplikacji, ale w kodzie ródowym projektu mona odwoywa si do kodu
umieszczonego w innych moduach. Odwoywanie si do kodu znajdujcego si w innych
moduach wymaga jednak jawnego zdefiniowania zalenoci pomidzy projektami,
co jest zilustrowane przykadem w dalszej czci rozdziau.
2.3.2. Zastosowanie projektu uytkowego

do przechowywania kodu warstwy biznesowej
Zaómy, e chcemy umoliwi rozwijanie aplikacji ISRP w dwóch projektach, tak
by kod warstwy prezentacji opartej na szkielecie JSF znajdowa si w jednym projek-
cie, a kod pozostaych warstw (biznesowej i dostpu do danych) w innym. Zalet ta-
kiego podziau bdzie moliwo wielokrotnego wykorzystania moduu zawierajcego
warstw biznesow w aplikacjach zawierajcych interfejsy oparte na rónych tech-
nologiach (np. JSF i Swing).
W materiaach pomocniczych do ksiki Czytelnik znajdzie m.in. kod moduu uyt-

kowego ISRPModel, zawierajcy implementacj warstwy biznesowej, udostpniony
w postaci zarchiwizowanego pliku projektu Eclipse oraz skompilowanej wersji mo-
duu w pliku JAR. Czytelnik, który chciaby pomin zagadnienia wytwarzania war-
stwy biznesowej, moe skorzysta z gotowego do uycia moduu ISRPModel i skupi
si wycznie na implementacji interfejsu uytkownika wedug wskazówek zamieszczo-
nych w nastpnych rozdziaach.
Na rysunku 2.10 przedstawiono struktur aplikacji ISRP, która skada si z moduów
Web Application oraz Utility Module. Modu Web Application zawiera kod warstwy
prezentacji i jest tworzony w rodowisku Eclipse przy uyciu projektu typu Dynamic
Web Project (przykad takiego projektu zosta zaprezentowany w rozdziale 1.). Modu
Utility Module przechowuje warstw biznesow aplikacji ISRP i jest tworzony w ro-
dowisku Eclipse przy uyciu projektu typu Utility Project.
Dynamic Web Project (WAR)
«library» Komponenty Komponenty Zasoby

JavaServer Faces wspierajce zarzdzane
Widoki JSP Walidatory i Filtry

konwertery
Utility Project (JAR)
Warstwa biznesowa
«interface»
Interfejsy warstwy usugowej
Implementacje Model dziedzinowy

usug (obiekty biznesowe)
Warstwa dostpu do danych
Obiekty DAO Odwzorowania OR

«library»
Hibernate
Rysunek 2.10. Struktura moduów aplikacji ISRP oraz zalenoci wystpujce pomidzy nimi
Projekt typu Java EE Utility Project jest bardzo podobny do zwykego projektu Javy
w rodowisku Eclipse, ale posiada dodatkowy pakiet rozszerze (tzw. facet) — Utility
Module (idea pakietów rozszerze Eclipse zostaa omówiona w rozdziale 1., w ramce
„JSF Facet”). Utility Module stanowi cz konfiguracji uruchomieniowej projektu
i umoliwia wykorzystanie skompilowanego kodu projektu w innych moduach aplikacji
korporacyjnej (Java EE). Gdy zmiany w projekcie zostan zapisane, Eclipse automa-
tycznie go skompiluje i spakuje kod wynikowy do pliku JAR, który nastpnie jest pu-
blikowany (bd aktualizowany) na serwerze oraz w innych projektach, które z niego
korzystaj.
Ze wzgldu na opisane wyej waciwoci Utility Project znakomicie nadaje si do

przechowywania kodu warstwy biznesowej oraz interfejsu warstwy trwaoci, oczy-
wicie pod warunkiem, e model dziedzinowy nie jest oparty na komponentach EJB
(w takim przypadku wymagany jest EJB Module).
W celu utworzenia nowego projektu Java EE Utility Project naley wykona nastpujce
kroki:
1. Z menu aplikacji wybieramy opcj File/New/Project. Pojawi si okno kreatora
New Project, w którym wywietli si lista typów projektów.
2. Na licie wskazujemy grup projektów korporacyjnych (Java EE). Po rozwiniciu
elementów grupy wybieramy opcj Utility Project i zatwierdzamy przyciskiem Next.
Wywietli si okno kreatora New Java Utility Module, pokazane na rysunku 2.11.
Rysunek 2.11.
Tworzenie projektu
typu Utility Project
3. W polu Project name wpisujemy nazw projektu. Nastpnie z listy rozwijanej

Target Runtime wybieramy rodowisko uruchomieniowe serwera, na którym
ma by publikowany kod wynikowy projektu. Aby doda kolejne pakiety
rozszerze Eclipse do projektu (np. dla szkieletu Spring), naley w sekcji
Configuration klikn przycisk Modify i w nowym oknie kreatora zaznaczy
odpowiednie pola wyboru. Wszystko zatwierdzamy przyciskiem Next
i przechodzimy do kolejnego okna, w którym moemy zaczy do projektu
dodatkowe róda. Cao zatwierdzamy przyciskiem Finish.
2.3.3. Moduy zalene

Istniej dwa sposoby wykorzystania gotowego moduu uytkowego w aplikacji, a miano-
wicie:
bezporednie wdroenie moduu uytkowego w rodowisku uruchomieniowym
serwera (opisane w poprzednim punkcie),
ustawienie zalenoci pomidzy projektami i wykorzystanie moduu uytkowego
podczas budowy innego moduu.
W drugim przypadku we waciwociach projektu Utility Project ustawiamy warto

<None> w polu Target Runtime. Aby doczy modu Utility Module do dowolnego
innego projektu Java EE, w oknie Project Explorer zaznaczamy projekt docelowy i z menu
kontekstowego wybieramy opcj Properties. Nastpnie w oknie waciwoci wybie-
ramy stron Java EE Module Dependencies, po czym zaznaczamy pole wyboru przy
nazwie projektu, którego skompilowany kod chcemy doczy , jak pokazano na ry-
sunku 2.12.
Rysunek 2.12.
Ustawianie zalenoci
pomidzy projektami
Java EE
Na przykad do budowy aplikacji ISRP wykorzystamy dwa projekty — projekt Dynamic

Web Project (DWP) do rozwijania kodu warstwy prezentacji oraz Utility Project (UP)
do rozwijania warstwy biznesowej oraz warstwy dostpu do danych. Poniewa ocze-
kiwanym moduem wynikowym aplikacji ma by aplikacja WWW, projekt DWP b-
dzie zaleny od UP. Po kadej kompilacji wynikowy modu Utility Module bdzie
automatycznie dodawany (zamieniany) do wynikowego pliku WAR oraz sekcji Web
App Libraries w ciece przeszukiwania projektu DWP. Jednoczenie kada zmiana
pliku WAR bdzie powodowa automatyczn publikacj nowej wersji aplikacji WWW
na serwerze, chyba e uytkownik zmieni domylne ustawienia dotyczce publiko-
wania (patrz rozdzia 6., rysunek 6.2).
Wszystkie klasy i doczone do projektu uytkowego biblioteki s widoczne w projekcie

zalenym. Klasy i biblioteki projektu zalenego nie s jednak widoczne w projekcie
uytkowym. Niestety, nie moemy zdefiniowa odwrotnej zalenoci, gdy spowo-
dowaoby to powstanie cyrkularnoci, która jest przez rodowisko Eclipse automa-
tycznie wykrywana i traktowana jako bd. Do powszechnym rozwizaniem tego
problemu jest umieszczenie kodu niezbdnych dla obu projektów klas w oddziel-
nym projekcie uytkowym (Utility Project). W takim przypadku dwa projekty s za-
lene od trzeciego i nie powstaje pomidzy nimi zaleno cyrkularna.

Jsfecg 2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Jsfecg 2

Uploaded by

Copyright:

Available Formats

Idź do JavaServer Faces i Eclipse

2.2. Warstwa biznesowa ................................................................................................. 77

4.2.3. Mechanizm zarzdzania widokami ............................................................ 238

Dodatek A Standardy kodowania IANA ........................................................... 353

2.1. Modelowanie interfejsu

Ze wzgldu na komponentowy charakter szkieletu JSF, scenopis wydaje si technik

Scenopis i metodyki modelowania,

Opierajc si na UML, stworzono metodyk projektowania oprogramowania RUP

w JSF zarzdzanie wymaganiami (ang. Requirement Management), uywanie archi-

Scenopis (ang. storyboard) jest modelem projektowym, zwykle tworzonym przez

2.1.1. Przypadki uycia

Na rysunku 2.1 przedstawiono diagram przypadków uycia modelujcy aktorów, przy-

Rysunek 2.1. Diagram przypadków uycia dla ISRP

Dokadny opis wykorzystania diagramów UC do modelowania funkcjonalnoci sys-

2.1.2. Model ekranów interfejsu uytkownika

W technice scenopisów standardowym elementom UML nadawane s nowe znaczenia

Tabela 2.1. Stereotypy modelu UI wykorzystywane w technice scenopisów

Zdarzenia generowane przez interfejs uytkownika oraz akcje uytkownika reprezen-

Nazwa operacji powinna by powizana z nazw metody sucej do obsugi zdarze-

Na rysunku 2.2 zaprezentowano model ekranu realizujcego dwa przypadki uycia

2.1.3. Model nawigacji

Wystpujce na diagramie asocjacje skierowane wskazuj kierunek przepywu stero-

Rysunek 2.2. Model ekranu rejestracji i edycji danych uytkownika

2.1.4. Prototypy ekranów

+ welcomeMessage: String registration_success «screen»

paper_details + globalMessages: String [0..*]

Rysunek 2.3. Diagram nawigacji dla aplikacji ISRP

W technice scenopisów generalnie zaleca si stosowanie projektów szkieletowych,

Przykad projektu szkieletowego dla ekranu rejestracji uytkownika w systemie ISRP

Rysunek 2.4. Projekt szkieletowy ekranu rejestracji aplikacji ISRP

2.1.5. Diagram maszyny stanowej

zaznaczenie zaznaczenie pola zatwierdzenie

+ entry / uaktywnij przycisk Zarejestruj

Rysunek 2.5. Diagram maszyny stanowej dla ekranu rejestracji

Stan pocztkowy reprezentuje stan kontrolera po utworzeniu jego instancji i jest

Przejcia s oznaczane za pomoc strzaek czcych dwa stany kontrolera i mog by

Przejcia wewntrzne nie maj odrbnego oznaczenia graficznego, lecz s specyfiko-

Przejcia wewntrzne lub zwrotne wystpuj w sytuacjach, gdy kompozycja ekranu

2.2. Warstwa biznesowa

2.2.1. Rola i elementy warstwy biznesowej

Najpopularniejsze podejcia do tworzenia warstwy biznesowej w aplikacjach WWW

Warstwa usugowa (fasady)

Model dziedzinowy (POJO)

Interfejs do warstwy trwaoci (DAO)

Programowanie komponentowe jest naturalnym rozszerzeniem programowania zo-

Do implementacji warstwy biznesowej w zawartych w ksice przykadach wykorzy-

Klasy POJO i komponenty JavaBean

Poniewa w aplikacjach korporacyjnych Java EE (J2EE) wymagane s dodatkowe

Komponenty JavaBean s to napisane w odpowiedniej konwencji klasy POJO, bdce

Przykadowymi komponentami JavaBean s komponenty wspierajce.

2.2.1.1. Model dziedzinowy

Dokadne odwzorowanie obiektowe koncepcji biznesowych wystpujcych w mode-

Rysunek 2.7. Diagram konceptualny systemu ISRP

W takich systemach podejcie komponentowe moe by przydatniejsze, a kontenery

Model dziedzinowy aplikacji ISRP zaimplementowany jest w postaci klas POJO.

Listing 2.1. Kod klasy User

public class User implements java.io.Serializable {

public User() { //konstruktor na potrzeby serializacji

public User(int countryId, String title, String firstName, String lastName,

public Integer getId() {return this.id;}

public void setId(Integer id) {this.id = id;}

/* ...Pozostae gettery i settery ...*/

Podejcie polegajce na wyprowadzeniu implementacji logiki biznesowej poza mo-

4.2.3. Mechanizm zarzdzania widokami ............................................................ 238

Ze wzgldu na komponentowy charakter szkieletu JSF, scenopis wydaje si technik

Opierajc si na UML, stworzono metodyk projektowania oprogramowania RUP

w JSF zarzdzanie wymaganiami (ang. Requirement Management), uywanie archi-

2.1.1. Przypadki uycia

Na rysunku 2.1 przedstawiono diagram przypadków uycia modelujcy aktorów, przy-

2.1.2. Model ekranów interfejsu uytkownika

W technice scenopisów standardowym elementom UML nadawane s nowe znaczenia

Nazwa operacji powinna by powizana z nazw metody sucej do obsugi zdarze-

Na rysunku 2.2 zaprezentowano model ekranu realizujcego dwa przypadki uycia

Wystpujce na diagramie asocjacje skierowane wskazuj kierunek przepywu stero-

W technice scenopisów generalnie zaleca si stosowanie projektów szkieletowych,

Stan pocztkowy reprezentuje stan kontrolera po utworzeniu jego instancji i jest

Przejcia s oznaczane za pomoc strzaek czcych dwa stany kontrolera i mog by

Przejcia wewntrzne nie maj odrbnego oznaczenia graficznego, lecz s specyfiko-

Przejcia wewntrzne lub zwrotne wystpuj w sytuacjach, gdy kompozycja ekranu

Do implementacji warstwy biznesowej w zawartych w ksice przykadach wykorzy-

Poniewa w aplikacjach korporacyjnych Java EE (J2EE) wymagane s dodatkowe

Komponenty JavaBean s to napisane w odpowiedniej konwencji klasy POJO, bdce

Przykadowymi komponentami JavaBean s komponenty wspierajce.

Dokadne odwzorowanie obiektowe koncepcji biznesowych wystpujcych w mode-

/* ...Pozostae gettery i settery ...*/

Podejcie polegajce na wyprowadzeniu implementacji logiki biznesowej poza mo-

Na przykad na diagramie przypadków uycia systemu ISRP wystpuje przypadek

Listing 2.2. Kod ródowy interfejsu PaperService

Implementacja metod interfejsu PaperService znajduje si w klasie PaperServiceImpl.

/* pobranie obiektów dostpowych do tabel — patrz listing 2.11*/

Listing 2.4. Kod ródowy interfejsu lokalizatora usug

Na listingu 2.5 przedstawiono kod klasy lokalizatora ServiceLocatorImpl, definiujcego

Listing 2.5. Kod ródowy lokalizatora usug ServiceLocatorImpl

Listing 2.6. Integracja warstwy usugowej w pliku faces-config.xml

2.2.2. Interfejs do warstwy trwaoci danych

Korzystajc z relacyjnych baz danych, naley zapewni odwzorowania obiektów Javy

W zasadzie dwa ostatnie rozwizania s do podobne — JPA byo wzorowane na

W dalszych punktach przyblione zostan najwaniejsze informacje dotyczce wyko-

Zasada dziaania Hibernate opiera si na zastosowaniu plików konfiguracyjnych defi-

Pliki mapowa Hibernate odpowiadaj za translacj danych znajdujcych si w tabeli

Instalacja Hibernate sprowadza si do pobrania i rozpakowania pakietów instalacyjnych,

Rysunek 2.8. Przykadowy diagram mapowania wygenerowany w HibernateTools

Listing 2.9. Implementacje podstawowych operacji dostpnych w DAO

Listing 2.10. Kod ródowy klasy UserDao

Rejestracja filtru w pliku web.xml w najprostszym schemacie bdzie mie nastpujc

Organizujc kod aplikacji, naley pamita, e HibernateSessionFilter jest elemen-

Pierwszych pi wymienionych typów moduów jest okrelonych w specyfikacji Java

2.3.2. Zastosowanie projektu uytkowego