JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW

Transkrypt

Idź do
• Spis treści
• Przykładowy rozdział
Katalog książek
JavaServer Faces i Eclipse
Galileo. Tworzenie
aplikacji WWW
Autor: Andrzej Marciniak
ISBN: 978-83-246-2656-4
Format: 158×235, stron: 384
• Katalog online
• Zamów drukowany
katalog
Twój koszyk
• Dodaj do koszyka
Cennik i informacje
• Zamów informacje
o nowościach
• Zamów cennik
Czytelnia
• Fragmenty książek
online
Kontakt
Helion SA
ul. Kościuszki 1c
44-100 Gliwice
tel. 32 230 98 63
e-mail: [email protected]
© Helion 1991–2010
• Jak projektować estetyczne i wygodne interfejsy użytkownika aplikacji WWW?
• 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
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
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
programistyczny jest obecnie najbardziej elastycznym, najlepiej dopracowanym i najprostszym
w użyciu rozwiązaniem, opartym na technologii serwletów.
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,
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,
zdobywając przy tym kompletną wiedzę na temat mechanizmów i rozwiązań zapewniających
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
WWW za pomocą szkieletu programistycznego JavaServer Faces
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
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
6
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 moliwoci 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 Internetowego Systemu Recenzowania Publikacji (w skrócie ISRP), przeznaczonego do
zapewnienia obsugi informatycznej pracy redakcji czasopism naukowych oraz
wspomagania organizacji konferencji naukowych. Zakres funkcjonalnoci projektowanego 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 przedstawienie pewnych praktyk projektowych zwizanych z architektur i projektowaniem
aplikacji JSF na platformie Java EE. Prezentowane rozwizania s wypadkow dowiadcze wielu osób w zakresie wykorzystania szkieletu JSF do wytwarzania warstwy prezentacji w aplikacjach o architekturze wielowarstwowej. Szczególna uwaga
powicona jest wybranym aspektom zwizanym z czynnociami fazy przedimplementacyjnej projektu, takim jak modelowanie interfejsu uytkownika oraz projektowanie aplikacji oparte na architekturze wielowarstwowej. Zamieszczone w tym rozdziale
model i zaoenia projektowe bd rozwijane w dalszej czci ksiki i stanowi jednoczenie odniesienie dla kolejnych przykadów ilustrujcych elementy technologii JSF.
68
2.1. Modelowanie interfejsu
uytkownika przy wykorzystaniu
techniki scenopisu
Jako modelu projektowanego systemu czsto decyduje o powodzeniu projektu informatycznego, a jego najbardziej podan cech jest kompromisowo. Model powinien by jednoczenie zrozumiay dla klientów, którzy na jego podstawie oceniaj
funkcjonalno systemu, jak te zawiera wszystkie niezbdne dane dla zespou projektowego, 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 niefunkcjonalnych), a jednoczenie nie powinien wymaga rozlegej wiedzy na ich temat od analitykó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 zapewniaj diagramy przypadków uycia i prototypy ekranów. W dalszej czci rozdziau zaprezentowane zostan poszczególne elementy scenopisu, ilustrowane wybranymi fragmentami modelu aplikacji ISRP.
Scenopis i metodyki modelowania,
projektowania i dokumentowania systemów informatycznych
Metodyki wytwarzania systemów informatycznych stanowi jeden z gównych nurtó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 informatycznego. UML jest uywany wraz z jego reprezentacj graficzn — jego elementom 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 standard dla modelowania zachowania i struktury aplikacji WWW, np. w zakresie modelowania 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 zawarte, 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 architektury bazujcej na komponentach (ang. Component-based Architecture) czy graficzne projektowanie oprogramowania.
Scenopis (ang. storyboard) jest modelem projektowym, zwykle tworzonym przez
analityków biznesowych i projektantów interfejsu uytkownika, dostarczonym zespoowi 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 postaci 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 wymaga funkcjonalnych s diagramy przypadków uycia (ang. Use Case — UC) w jzyku UML. Ilustruj one funkcjonalno systemu poprzez wyszczególnienie i przedstawienie za pomoc symboli graficznych: aktorów inicjujcych dziaania, przypadków
uycia systemu oraz wystpujcych pomidzy nimi zwizków. Dziki swojej prostocie oraz abstrahowaniu od rozwiza technicznych, diagramy przypadków uycia s
zrozumiae nawet dla osób, które nie posiadaj wyksztacenia informatycznego. Z zaoenia 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, przypadki uycia oraz powizania pomidzy nimi, wystpujce w systemie ISRP. Schematyczny 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 zawierania dla przypadków uycia opisane s przy zastosowaniu stereotypów umieszczonych w cudzysowach ostroktnych. Relacje uogólniania (w sensie zwizku taksonomicznego, opisujcego dziedziczenie cech) przedstawione zostay za pomoc linii
zakoczonych strzak z pustym grotem.
70
Zaloguj
Odzyskaj haso
Wywietl szczegóy
recenzji
Edytuj dane osobowe
Autor
(from Actors)
Poka szczegóy
pracy
Dodaj prac
Uytkownik
uwierzytelniony
Wywietl list prac
(from Actors)
«extend»
Zarejestruj
Edytuj prac
«include»
Recenzent
(from Actors)
Dodaj recenzj
Zarzdzaj pracami
Wywietl list
recenzji
Przypisz recenzenta
do pracy
Dodaj recenzenta
Administrator
(from Actors)
Zarzdzaj
uytkownikami
«include»
Wywietl list
uytkowników
Rysunek 2.1. Diagram przypadków uycia dla ISRP
Dokadny opis wykorzystania diagramów UC do modelowania funkcjonalnoci systemu Czytelnik znajdzie w ksice Jzyk UML 2.0 w modelowaniu systemów informatycznych, 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 aplikacji, 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.
71
oba zespoy. Model ekranów UI definiuje zbiór ekranów (wraz z ich zawartoci) niezbdnych do zrealizowania wymaga funkcjonalnych okrelonych przez przypadki
uycia. W przypadku zawartoci ekranów model definiuje wycznie elementy funkcjonalne, 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).
Compartment
Class
Fragment ekranu (strony WWW) przeznaczony do
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 reprezentowane w modelu UI. Dane biznesowe s przedstawiane na ekranie przy uyciu atrybutó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 wycznie dla administratora systemu. Pole suce do wprowadzania uprawnie dla nowego 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 danych 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 moe 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 waciwoci atrybutu s opcjonalne i nie musz by definiowane. Liczebno okrela, ile instancji 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 reprezentowane s za pomoc operacji. Jeli operacja jest dodatkowo opatrzona stereotypem
<<submit>>, oznacza to, e wskazany element UI suy do zatwierdzania formularza
72
i generowania akcji, której wynik moe wpywa na nawigacj aplikacji. Peny opis operacji 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 nastpujcy sposób:
<<submit>> + edit ():String {current.user==notEmpty}
Nazwa operacji powinna by powizana z nazw metody sucej do obsugi zdarzenia 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 zamieszczane 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 uwierzytelnionego. 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 przypadku rejestracji nowego uytkownika elementy menu leftMenu oraz przycisk zapisywania 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 przepywie zdarze, ale pokazuj zwizki pomidzy ekranami. Model nawigacji zawiera
graficzn ilustracj przepywów nawigacji dla wszystkich przypadków uycia. Przepywy nawigacji dla poszczególnych przypadków mog by prezentowane na oddzielnych 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 sterowania 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 nazw, która bdzie moga zosta wykorzystana podczas definiowania regu nawigacji
JSF (jako warto elementu <from-outcome>).
«screen»
addEditUser
+
73
«compartment»
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»
+ city: text
+ country: select
+ department: text
+ firstName: text
+ gender: radio
+ lastName: text
+ password: text
+ phone: text
+ role {user.role==admin}: select
+ street: text
+ title: text
+ zipCode: text
«compartment»
includes::topMenu
+
userName {user==authorized}: String
+
+
english() : void
polish() : void
«submit»
+ login {user==notAuthorized}() : String
+ logout {user==authorized}() : String
+ registration {user==notAuthorized}() : String
«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 kluczowych 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. prototypowanie, 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 umoliwiajce testowanie ekranu na faszywych danych. Projekty szkieletowe nie uwzgldniaj szaty graficznej, a ich celem jest przedstawienie ogólnej funkcjonalnoci poszczególnych ekranów oraz sposobu prezentacji danych biznesowych.
74
«screen»
forgotPassword
«screen»
assignReviewer
{user.role==admin}
+ globalMessage: String [0..*]
«input»
+ email: text
+ paper.title: String
«input»
+ reviewers: select
«submit»
+ forgotPassword() : String
+ notRegistered() : String
login
assign_reviewer
assign_success
registration
«compartment»
:topMenu
logout_success
registration
«screen»
index
globalMessages: String [0..*]
+ welcomeMessage: String
paper_details
«screen»
addEditUser
registration_success
delete
all_papers_list
«compartment»
:leftMenu
«screen»
addReview
{user.role==reviewer}
add_user
edit_user
+ globalMessages: String [0..*]
«screen»
paperDetails
+
+
+
+
login_success
get_password_success
«screen»
papersList {user.role==admin}
+
forgot_password
«submit»
+ getNewPassword() : String
«submit»
+ assign() : String
aprove/reject
«screen»
login
paper.abstract: String
paper.acronym: String
paper.authors: String
paper.title: String
add_success
author_papers_list
papers_details
all_users_list
«screen»
reviewerPaperList
+ globalMessages: Strin [0..*]
«screen»
usersList {user.role==admin}
«submit»
+ downloadFile() : void
review_details
review_details
edit_success
add_success reviewer_papers_list
add_review
+ globalMessages: String [0..*]
paper_details
«screen»
auhtorPaperList
{user.role==author}
«screen»
reviewDetails
+
delete
globalMessages: String [0..*]
+ review.commentToAdmin {user.role==admin || user.role==reviewer}: String
+ review.commentToAuthor {user.role==author || user.role==reviewer}: String
+ review.grade: String
add_success
edit_paper
review_details
add_paper
add_new_version
edit_success
«screen»
addNewVersion
{user.role==author}
add_success
«screen»
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 — utworzone w ten sposób projekty mog by póniej stosowane podczas implementacji.
75
Przykad projektu szkieletowego dla ekranu rejestracji uytkownika w systemie ISRP
zosta pokazany na rysunku 2.4. Projekt stanowi rozwinicie modelu ekranu zamieszczonego na rysunku 2.2 zarówno w zakresie specyfikacji kontrolek realizujcych elementy 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 ekranu 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 maszyny stanowej, ilustrujcy zmiany stanów kontrolera ekranu rejestracji (przedstawionego na rysunku 2.4).
76
«ControllerState»
Rejestracja nieaktywna
wyjcie po
klikniciu przycisku
nawigacji
Final
+
entry / dezaktywuj przycisk Zarejestruj
start
zaznaczenie
pola wyboru
[pole=true]
zaznaczenie pola
wyboru
[pole=false]
zatwierdzenie
formularza [walidacja
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 kontroler 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 nawigacji 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.
77
Przejcia wewntrzne nie maj odrbnego oznaczenia graficznego, lecz s specyfikowane 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 zmienne mog zosta usunite.
2.2. Warstwa biznesowa
W rozdziale 1.2.4, „Implementacja MVC w JSF”, przedstawiono ogólny schemat implementacji wzorca MVC w aplikacjach opartych na JSF oraz korzyci pynce z izolowania 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 modelowane s obiekty i reguy biznesowe. Stanowi ona zazwyczaj rdze aplikacji i jest
najbardziej rozleg jej warstw, z jednej strony wiadczc usugi dla warstwy prezentacji, 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 prezentacji uatwia implementacj regu biznesowych i umoliwia uycie obiektów biznesowych 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 oddzielone i posiadaj cile zdefiniowane zakresy odpowiedzialnoci, tj. model dziedzinowy, 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).
78
Rysunek 2.6.
Warstwowy model
architektury
wykorzystany
w aplikacji ISRP
Warstwa prezentacji
Warstwa biznesowa
Warstwa usugowa (fasady)
Model dziedzinowy (POJO)
Interfejs do warstwy trwaoci (DAO)
Warstwa trwaoci
Programowanie komponentowe jest naturalnym rozszerzeniem programowania zorientowanego obiektowo — nie posiada ono zupenie nowych atrybutów w stosunku
do programowania obiektowego, a jedynie konsekwentnie i w peni wykorzystuje cechy obiektowoci. Komponenty oferuj hermetycznie opakowane, wysokopoziomowe
funkcje realizujce logik biznesow. Zarzdzaniem komponentami zajmuje si kontener, który kontroluje róne aspekty ich ycia, m.in. tworzenie instancji, wprowadzanie zalenoci pomidzy nimi czy te zarzdzanie cyklem ich ycia. Kontener pozwala na ograniczenie zada stojcych przed komponentami do realizacji jedynie
funkcji biznesowych, dziki czemu s one atwe do zrozumienia, maj czytelne interfejsy 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 porozumiewaniem si komponentów czy zoonoci infrastruktur rodowisk uruchomieniowych. Popularnymi technologiami komponentów s Enterprise Java Beans czy Spring.
Do implementacji warstwy biznesowej w zawartych w ksice przykadach wykorzystywane jest podejcie oparte na klasach POJO. Zalet tego podejcia jest brak zalenoci 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 predefiniowanych 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 wykorzystania prostych technik projektowych w programowaniu obiektowym.
79
Poniewa w aplikacjach korporacyjnych Java EE (J2EE) wymagane s dodatkowe
usugi, takie jak zarzdzanie transakcjami, utrzymywanie bezpieczestwa czy trwaoci danych (w alternatywnym podejciu usugi te zapewniaj kontenery EJB), powstay specjalne lekkie szkielety programistyczne (ang. lightweight frameworks), udostpniajce 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 metod, 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-, seti 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 modelowanym 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 drobnoziarnistym wystpuje mnóstwo wzajemnych odwoa pomidzy obiektami, co stanowi
problem w systemach rozproszonych, gdy zdalne wywoania s do kosztowne.
80
java.io.Serializable
Uytkownik
mieszka
wykonuje
Recenzja
nadsya
Kraj
Artyku
Pytanie
Odpowied
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 listingu 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) {
81
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 model 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 hermetyzacji 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 narzdzi 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 funkcjonalnoci 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 odpowiadajce 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 „Wzorzec fasady”) oraz implementowa procesy biznesowe.
82
Na przykad na diagramie przypadków uycia systemu ISRP wystpuje przypadek
Przypisz recenzenta do pracy, który reprezentuje zoony proces biznesowy. W ramach tego procesu zachodzi nastpujca sekwencja czynnoci: redaktor z uprawnieniami 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 zamieszczony na listingu 2.2. Zgodnie z dobr praktyk programowania obiektowego,
polegajc na przedkadaniu interfejsów nad implementacje, wszystkie metody wymagane 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 zosta wycznie jego fragment, zawierajcy deklaracj klasy oraz implementacj metody
odpowiedzialnej za przypisanie recenzenta i wysanie powiadomienia poczt elektroniczn.
Listing 2.3. Implementacja interfejsu PaperService
public class PaperServiceImpl implements PaperService{
public PaperServiceImpl() {}// bezargumentowy konstruktor
public void assignReviewer(Paper paper, int reviewerId,
EmailConfiguration emailConfiguration) {
83
/* 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 strukturalnych 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 uzyskania tej funkcjonalnoci.
2.2.1.3. Lokalizatory usug
Usugi biznesowe powinny by atwo dostpne dla wszelkiego typu klientów, niezalenie 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 opisanego w rozdziale 1., w ramce „Wzorzec delegata biznesowego”). Obiekt lokalizatora tworzy jeden punkt dostpowy do kodu warstwy biznesowej, jednoczenie zmniejszajc 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.
84
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
private
private
private
private
PaperService paperService;
UserService userService;
ReviewService reviewService;
CountryService countryService;
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;}
}
85
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 pierwszego 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 dostp 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 stosowaniu 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 przesyanych 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 danych. Interfejs do warstwy trwaoci powinien cakowicie oddziela szczegóy technologii 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.
86
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 wykorzystania 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 warstwy 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 definiowanych 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 konfiguracyjnego dla aplikacji ISRP zosta przedstawiony na listingu 2.7. Znaczenie poszczegó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>
87

<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 element przyrostka jest skrótem od wyraenia „HiBernate Mapping”. Poniej zamieszczono
fragment pliku mapowania User.hbm.xml. Diagram penego mapowania przykadowej 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.
88
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 programistyczne w Eclipse”. Wówczas w polu Work with menedera instalacji wpisujemy 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 projektow 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.
89
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();
}
}
90
Zastosowanie klasy abstrakcyjnej GenericDao pozwala na znaczne uproszczenie implementacji 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();
}
}
91
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 rodowisku 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 problemem w przypadku serwerów aplikacji, ale przy korzystaniu z prostych kontenerów
serwletów, takich jak Tomcat, stanowi to utrudnienie, gdy naley samodzielnie zapewni kontekst pocztkowy. Tomcat wprawdzie dostarcza wasny obiekt kontekstowy
JNDI, ale nie mona go modyfikowa z poziomu kodu aplikacji (jest tylko do odczytu), 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 uycia DAO równie istotnym problemem jest zapewnienie atwej lokalizacji obiektów
poprzez centralizacj dostpu. W przypadku interfejsu do warstwy trwaoci centralizacja ma za zadanie uatwienie tworzenia obiektów DAO oraz zamiany ich implementacji. Dostarczenie interfejsu do tworzenia rónych obiektów implementujcych
wspólny interfejs bez specyfikowania ich konkretnych klas zapewnia wzorzec projektowy 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 zaprezentowana zostaa na listingu 2.11, a jej implementacja na listingu 2.12. Przykady
wykorzystania fabryki obiektów do tworzenia DAO w warstwie usugowej zaprezentowano 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;
}
92
public
public
public
public
public
public
abstract
abstract
abstract
abstract
abstract
abstract
UserDao getUserDao();
CountryDao getCountryDao();
PaperDao getPaperDao();
QuestionDao getQuestionDao();
ReviewDao getReviewDao();
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);
93
}
}
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. wygenerowaniu 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 Applications 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, realizowane w trakcie przetwarzania dania HTTP. Transakcja jest zatwierdzana dopiero
po zakoczeniu przetwarzania dania. Filtr zawiera obsug wszelkich wyjtków i bdó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 wycofywane (rollback). W kodzie do pobrania biecej sesji Hibernate uyto klasy pomocniczej 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.
94
<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 tworzona zawsze, równie dla tych da HTTP, których przetwarzanie nie wymaga poczenia 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 aplikacj 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 elementem warstwy widoku aplikacji WWW, podczas gdy klasa HibernateUtil zapewnia
dostp do warstwy trwaoci.
Klient
Kontener Web
Hibernate Filter
HibernateUtil
95
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 rodowisku Eclipse Web Tools Platform, a mianowicie projekt i modu aplikacji.
96
Wszystkie pliki ródowe oraz inne zasoby aplikacji bd biblioteki musz by umieszczone 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 metadanych, które zawieraj pomocnicze informacje o wymaganych zasobach zewntrznych, sposobie kompilacji czy rodowisku uruchomieniowym. Logiczna struktura
prezentowanych w oknie Project Explorer katalogów i zasobów projektu jest zoptymalizowana pod ktem uatwienia pracy deweloperom.
Modu aplikacji (ang. module) reprezentuje gotowy do wdroenia na serwerze aplikacji kod wynikowy projektu (powstay po jego skompilowaniu), który moe by reprezentowany 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 spakowanych 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 projekcie, a kod pozostaych warstw (biznesowej i dostpu do danych) w innym. Zalet takiego podziau bdzie moliwo wielokrotnego wykorzystania moduu zawierajcego
warstw biznesow w aplikacjach zawierajcych interfejsy oparte na rónych technologiach (np. JSF i Swing).
97
W materiaach pomocniczych do ksiki Czytelnik znajdzie m.in. kod moduu uytkowego ISRPModel, zawierajcy implementacj warstwy biznesowej, udostpniony
w postaci zarchiwizowanego pliku projektu Eclipse oraz skompilowanej wersji moduu w pliku JAR. Czytelnik, który chciaby pomin zagadnienia wytwarzania warstwy biznesowej, moe skorzysta z gotowego do uycia moduu ISRPModel i skupi
si wycznie na implementacji interfejsu uytkownika wedug wskazówek zamieszczonych 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 rodowisku Eclipse przy uyciu projektu typu Utility Project.
Dynamic Web Project (WAR)
«library»
JavaServer Faces
Komponenty
wspierajce
Komponenty
zarzdzane
Zasoby
Widoki JSP
Walidatory i
konwertery
Filtry
Utility Project (JAR)
Warstwa biznesowa
«interface»
Interfejsy warstwy usugowej
Implementacje
usug
Model dziedzinowy
(obiekty biznesowe)
Warstwa dostpu do danych
«library»
Hibernate
Obiekty DAO
Odwzorowania OR
Rysunek 2.10. Struktura moduów aplikacji ISRP oraz zalenoci wystpujce pomidzy nimi
98
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 automatycznie go skompiluje i spakuje kod wynikowy do pliku JAR, który nastpnie jest publikowany (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, oczywicie 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
99
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 mianowicie:
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 wybieramy stron Java EE Module Dependencies, po czym zaznaczamy pole wyboru przy
nazwie projektu, którego skompilowany kod chcemy doczy, jak pokazano na rysunku 2.12.
Rysunek 2.12.
Ustawianie zalenoci
pomidzy projektami
Java EE
100
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 oczekiwanym moduem wynikowym aplikacji ma by aplikacja WWW, projekt DWP bdzie 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 publikowania (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 spowodowaoby to powstanie cyrkularnoci, która jest przez rodowisko Eclipse automatycznie wykrywana i traktowana jako bd. Do powszechnym rozwizaniem tego
problemu jest umieszczenie kodu niezbdnych dla obu projektów klas w oddzielnym projekcie uytkowym (Utility Project). W takim przypadku dwa projekty s zalene od trzeciego i nie powstaje pomidzy nimi zaleno cyrkularna.

JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW

Transkrypt

Podobne dokumenty

więcej

Zadania