J2EE. Wzorce projektowe

1. IDZ DO PRZYK£ADOWY ROZDZIA£ SPIS TRE CI J2EE. Wzorce projektowe KATALOG KSI¥¯EK Autorzy: Deepak Alur, John Crupi, Dan Malks KATALOG ONLINE T³umaczenie: Maciel Gorywoda ISBN: 83-7197-988-6 ZAMÓW DRUKOWANY KATALOG Tytu³ orygina³u: Core J2EE Patterns Format: B5, stron: 360 TWÓJ KOSZYK DODAJ DO KOSZYKA W ci¹gu ostatnich kilku lat Java 2 Enterprise Edition sta³a siê standardow¹ platform¹ do budowy skomplikowanych aplikacji. Poniewa¿ jest ona rozbudowanym rodowiskiem programistycznym, pozwalaj¹cym projektowaæ i programowaæ potê¿ne aplikacje, CENNIK I INFORMACJE nie jest ³atwa w obs³udze. W ksi¹¿ce, któr¹ trzymasz w rêku, do wiadczeni architekci Sun Java Center, organizacji konsultingowej, dzia³aj¹cej w ramach Sun Java, dziel¹ siê ZAMÓW INFORMACJE z czytelnikiem swoim do wiadczeniem w projektowaniu aplikacji opartych na O NOWO CIACH technologii J2EE. Autorzy skupiaj¹ siê na wzorcach projektowych, opartych na najwa¿niejszych ZAMÓW CENNIK technologiach J2EE, takich jak Java Server Pages (JSP), serwlety, Enterprise JavaBeans (EJB) oraz Java Message Service (JMS). Omawiane s¹ równie¿ inne technologie Javy, wa¿ne dla prawid³owej implementacji wzorców, takie jak JDBC i JNDI. CZYTELNIA Katalog zawieraj¹cy wzorce projektowe J2EE dokumentuje i prezentuje najlepsze sposoby wykorzystania tych technologii. To jednak nie wszystko. Ksi¹¿ka omawia FRAGMENTY KSI¥¯EK ONLINE równie¿: • wiele strategii przydatnych przy projektowaniu warstw prezentacyjnej i biznesowej; • identyfikacjê b³êdnych technik znajdywanych w warstwach prezentacyjnej, biznesowej i integracyjnej oraz propozycje rozwi¹zañ wykorzystuj¹cych wzorce projektowe oraz sposoby przebudowy systemów; • metody przebudowy dla poszczególnych warstw aplikacji oraz techniki zastêpowania b³êdnych implementacji prawid³owymi; • przyk³adowy kod programów opartych na omawianych strategiach i wzorcach projektowych. Wydawnictwo Helion ul. Chopina 6 44-100 Gliwice tel. (32)230-98-63 e-mail: helion@helion.pl

2. Spis treści Podziękowania 9 Przedsłowie I 11 Przedsłowie II 12 Wstęp 13 Część I Wzorce i J2EE 19 Rozdział 1. Wprowadzenie 21 Czym jest J2EE? .................................................................................................................... 21 Czym są wzorce?................................................................................................................... 22 Historia ............................................................................................................................ 22 Definicja wzorca............................................................................................................... 23 Kategorie wzorców ........................................................................................................... 24 Katalog wzorców J2EE ........................................................................................................... 25 Nieprzerwana ewolucja .................................................................................................... 25 Jak korzystać z katalogu wzorców J2EE ........................................................................... 26 Korzyści wynikające z używania wzorców ......................................................................... 27 Wzorce, struktury oraz powtórne wykorzystanie..................................................................... 29 Podsumowanie ...................................................................................................................... 29 Rozdział 2. Omówienie platformy J2EE 31 Krótko o historii..................................................................................................................... 31 Serwery aplikacji — nowe pokolenie................................................................................ 32 Właściwości technologii Javy ........................................................................................... 33 Powstanie platformy J2EE................................................................................................ 34 Ocena wartości J2EE ....................................................................................................... 34 Platforma J2EE ...................................................................................................................... 35 Architektura J2EE............................................................................................................. 35 Java 2 Standard Edition................................................................................................... 36 Komponenty i pojemniki aplikacji J2EE ............................................................................ 37 Serwisy standardowe....................................................................................................... 38 Role w platformie J2EE .................................................................................................... 39 Pliki opisów rozmieszczenia............................................................................................. 40 Wzorce J2EE a platforma J2EE .............................................................................................. 41 Podsumowanie ...................................................................................................................... 42

3. 4 J2EE. Wzorce projektowe Część II Elementy projektów, niewłaściwe techniki oraz przebudowa systemu 43 Rozdział 3. Elementy projektów oraz niewłaściwe techniki warstwy prezentacyjnej 45 Elementy projektowania warstwy prezentacyjnej.................................................................... 45 Zarządzanie sesją ............................................................................................................ 45 Kontrola praw dostępu klienta ......................................................................................... 48 Walidacja ......................................................................................................................... 52 Właściwości klas pomocniczych — integralność i konsekwencja..................................... 54 Niewłaściwe techniki zarządzania warstwą prezentacyjną...................................................... 56 Kontrola kodu w widokach wielokrotnych......................................................................... 57 Udostępnianie struktur danych warstwy prezentacyjnej warstwie komercyjnej ................. 57 Udostępnianie struktur danych warstwy prezentacyjnej obiektom rodzimym.................... 58 Powielanie wysyłanych formularzy.................................................................................... 58 Bezpośrednie udostępnianie ważnych zasobów............................................................... 59 Założenie, że <jsp:setProperty> będzie resetować własności komponentu ..................... 59 Tworzenie „grubych” sterowników.................................................................................... 60 Rozdział 4. Elementy projektów oraz niewłaściwe techniki warstwy komercyjnej 61 Elementy projektowania warstwy komercyjnej ....................................................................... 61 Korzystanie z komponentów sesyjnych ............................................................................ 61 Korzystanie z komponentów jednostkowych .................................................................... 65 Pamięć podręczna dla odległych referencji i uchwytów EnterpriseBeans ......................... 67 Niewłaściwe techniki zarządzania warstwą komercyjną ......................................................... 67 Mapowanie modelu obiektu bezpośrednio na model jednostki ........................................ 67 Mapowanie modelu relacji bezpośrednio na model jednostki .......................................... 68 Mapowanie każdego rodzaju wykorzystania na komponent sesyjny ................................. 69 Obsługa wszystkich atrybutów komponentu poprzez metody zmiany lub dostępu............ 69 Umieszczenie serwisu aktualizującego w aplikacjach klienckich...................................... 69 Używanie jednostki w charakterze obiektu tylko do odczytu............................................. 70 Używanie jednostek w charakterze obiektów wyspecjalizowanych.................................... 71 Przechowywanie pełnej struktury obiektów zależnych od jednostki .................................. 72 Niepotrzebne ujawnianie wyjątków związanych z EJB ....................................................... 72 Używanie metod przeszukujących komponentów jednostkowych do zwracania dużych bloków danych ............................................................................. 73 Klient sortujący dane dla komponentów komercyjnych .................................................... 73 Używanie EnterpriseBeans do obsługi transakcji czasochłonnych ................................... 74 Niezachowujące stanu komponenty odtwarzają stan konwersacji dla każdego wywołania...... 74 Rozdział 5. Sposoby przebudowy J2EE 77 Sposoby przebudowy warstwy prezentacyjnej ........................................................................ 77 Korzystanie ze sterownika ............................................................................................... 77 Korzystanie z synchronizatora.......................................................................................... 79 Wyodrębnienie procedur rozproszonych ........................................................................... 83 Ukrycie danych warstwy prezentacyjnej przed warstwą komercyjną.................................. 89 Usuwanie konwersji z widoku........................................................................................... 92 Ukrywanie zasobów przed klientem ................................................................................. 95 Sposoby przebudowy warstwy komercyjnej i integracyjnej ..................................................... 98 Zamknięcie komponentów jednostkowych w sesji............................................................ 98 Korzystanie z delegatów komercyjnych .......................................................................... 100 Łączenie komponentów sesyjnych ................................................................................. 101 Ograniczanie komunikacji międzyjednostkowej .............................................................. 102 Przesunięcie procedur komercyjnych do sesji ................................................................ 104

4. Spis treści 5 Ogólne sposoby przebudowy ............................................................................................... 105 Separacja kodu dostępu do danych............................................................................... 105 Przebudowa architektury warstw .................................................................................... 107 Korzystanie z zestawu połączeń..................................................................................... 109 Część III Katalog wzorców J2EE 111 Rozdział 6. Omówienie wzorców J2EE 113 Czym jest wzorzec?........................................................................................................ 113 Identyfikacja wzorca....................................................................................................... 114 Podejście warstwowe .......................................................................................................... 115 Wzorce J2EE........................................................................................................................ 117 Wzorce warstwy prezentacyjnej ...................................................................................... 117 Wzorce warstwy komercyjnej.......................................................................................... 117 Wzorce warstwy integracyjnej......................................................................................... 117 Wprowadzenie do katalogu.................................................................................................. 118 Terminologia .................................................................................................................. 118 Korzystanie z UML ......................................................................................................... 121 Szablon wzorców............................................................................................................ 122 Relacje pomiędzy wzorcami J2EE ........................................................................................ 123 Relacje do innych znanych wzorców .................................................................................... 126 Mapa wzorców..................................................................................................................... 126 Podsumowanie .................................................................................................................... 130 Rozdział 7. Wzorce warstwy prezentacyjnej 131 Filtr przechwytujący.............................................................................................................. 131 Kontekst ........................................................................................................................ 131 Problem ......................................................................................................................... 131 Siły................................................................................................................................. 132 Rozwiązanie ................................................................................................................... 132 Konsekwencje................................................................................................................ 145 Relacje z innymi wzorcami ............................................................................................. 146 Sterownik frontalny.............................................................................................................. 146 Kontekst ........................................................................................................................ 146 Problem ......................................................................................................................... 146 Siły................................................................................................................................. 147 Rozwiązanie ................................................................................................................... 147 Konsekwencje................................................................................................................ 156 Relacje z innymi wzorcami ............................................................................................. 156 Pomocnik widoku ................................................................................................................ 157 Kontekst ........................................................................................................................ 157 Problem ......................................................................................................................... 157 Siły................................................................................................................................. 157 Rozwiązanie ................................................................................................................... 158 Konsekwencje................................................................................................................ 169 Relacje z innymi wzorcami ............................................................................................. 169 Widok złożony...................................................................................................................... 170 Kontekst ........................................................................................................................ 170 Problem ......................................................................................................................... 170 Siły................................................................................................................................. 170 Rozwiązanie ................................................................................................................... 170

5. 6 J2EE. Wzorce projektowe Konsekwencje................................................................................................................ 177 Przykładowy kod............................................................................................................. 178 Relacje z innymi wzorcami ............................................................................................. 179 Struktura usługa-pracownik ................................................................................................. 180 Kontekst ........................................................................................................................ 180 Problem ......................................................................................................................... 180 Siły................................................................................................................................. 180 Rozwiązanie ................................................................................................................... 181 Konsekwencje................................................................................................................ 185 Przykładowy kod............................................................................................................. 186 Relacje z innymi wzorcami ............................................................................................. 191 Widok przekaźnika............................................................................................................... 191 Kontekst ........................................................................................................................ 191 Problem ......................................................................................................................... 192 Siły................................................................................................................................. 192 Rozwiązanie ................................................................................................................... 192 Konsekwencje................................................................................................................ 197 Przykładowy kod............................................................................................................. 198 Relacje z innymi wzorcami ............................................................................................. 202 Rozdział 8. Wzorce warstwy komercyjnej 203 Delegat komercyjny ............................................................................................................. 203 Kontekst ........................................................................................................................ 203 Problem ......................................................................................................................... 203 Siły................................................................................................................................. 204 Rozwiązanie ................................................................................................................... 204 Konsekwencje................................................................................................................ 208 Przykładowy kod............................................................................................................. 209 Relacje z innymi wzorcami ............................................................................................. 213 Obiekt wartości ................................................................................................................... 213 Kontekst ........................................................................................................................ 213 Problem ......................................................................................................................... 213 Siły................................................................................................................................. 214 Rozwiązanie ................................................................................................................... 214 Konsekwencje................................................................................................................ 223 Przykładowy kod............................................................................................................. 224 Relacje z innymi wzorcami ............................................................................................. 235 Fasada sesji ........................................................................................................................ 235 Kontekst ........................................................................................................................ 235 Problem ......................................................................................................................... 235 Siły................................................................................................................................. 237 Rozwiązanie ................................................................................................................... 237 Konsekwencje................................................................................................................ 241 Przykładowy kod............................................................................................................. 243 Relacje z innymi wzorcami ............................................................................................. 249 Jednostka złożona............................................................................................................... 250 Kontekst ........................................................................................................................ 250 Problem ......................................................................................................................... 250 Siły................................................................................................................................. 252 Rozwiązanie ................................................................................................................... 253 Konsekwencje................................................................................................................ 259

6. Spis treści 7 Przykładowy kod............................................................................................................. 260 Relacje z innymi wzorcami ............................................................................................. 269 Asembler obiektów wartości................................................................................................ 269 Kontekst ........................................................................................................................ 269 Problem ......................................................................................................................... 269 Siły................................................................................................................................. 272 Rozwiązanie ................................................................................................................... 273 Konsekwencje................................................................................................................ 276 Przykładowy kod............................................................................................................. 277 Relacje z innymi wzorcami ............................................................................................. 281 Uchwyt listy wartości ........................................................................................................... 281 Kontekst ........................................................................................................................ 281 Problem ......................................................................................................................... 282 Siły................................................................................................................................. 282 Rozwiązanie ................................................................................................................... 283 Konsekwencje................................................................................................................ 286 Przykładowy kod............................................................................................................. 287 Relacje z innymi wzorcami ............................................................................................. 292 Lokalizator usług ................................................................................................................. 292 Kontekst ........................................................................................................................ 292 Problem ......................................................................................................................... 293 Siły................................................................................................................................. 294 Rozwiązanie ................................................................................................................... 295 Konsekwencje................................................................................................................ 302 Przykładowy kod............................................................................................................. 302 Relacje z innymi wzorcami ............................................................................................. 306 Rozdział 9. Wzorce warstwy integracyjnej 307 Obiekt dostępu do danych................................................................................................... 307 Kontekst ........................................................................................................................ 307 Problem ......................................................................................................................... 307 Siły................................................................................................................................. 308 Rozwiązanie ................................................................................................................... 308 Konsekwencje................................................................................................................ 312 Przykładowy kod............................................................................................................. 314 Relacje z innymi wzorcami ............................................................................................. 320 Aktywator usług ................................................................................................................... 320 Kontekst ........................................................................................................................ 320 Problem ......................................................................................................................... 320 Siły................................................................................................................................. 321 Rozwiązanie ................................................................................................................... 321 Konsekwencje................................................................................................................ 324 Przykładowy kod............................................................................................................. 325 Relacje z innymi wzorcami ............................................................................................. 330 Dodatki 331 Epilog 333 Bibliografia 345 Skorowidz 349

7. 5 Sposoby przebudowy J2EE Sposoby przebudowy warstwy prezentacyjnej W tym podrozdziale zajmiemy się sposobami przebudowy warstwy prezentacyjnej. Korzystanie ze sterownika Procedury sterowania są rozproszone po całym kodzie aplikacji — zazwyczaj powielane są w wielu widokach stron serwerowych Javy (Java Server Pages, JSP). Procedury sterowania nale y wyodrębnić w przynajmniej jednej klasie sterowników. Klasy te odgrywają główną rolę w procesie obsługi ądań klientów. Rysunek 5.1. Korzystanie ze sterownika

8. 78 Część II n Elementy projektów, niewłaściwe techniki oraz przebudowa systemu Motywacja Powielany na ró nych stronach JSP kod sterowania musi być przez ka dą z nich utrzymy- wany. Wyodrębnienie takiego kodu w jednej klasie lub w większej ilości klas sterownika zwiększa przejrzystość oraz mo liwości wielokrotnego wykorzystania aplikacji, a tak e ułatwia jej utrzymanie. Mechanika n Klasę sterownika nale y utworzyć za pomocą wzorca klasy wydobycia (Extract Class [Fowler]) oraz wzorca sterownika frontalnego. Pozwala to na przeniesienie procedur sterowania z poszczególnych stron JSP do powstałego w ten sposób sterownika. n Przejdź do akapitu „Sterownik frontalny” (strona 146). n Nale y pamiętać, e klasa sterownika stanowi punkt wyjścia w procesie sterowania obsługą ądań. Strukturę kodu aplikacji musi cechować modularność oraz mo liwość wielokrotnego wykorzystania. Czasami zamiast tworzenia pojedynczego sterownika konieczne jest utworzenie obiektów pomocniczych i rozmieszczenie w nich kodu sterowania. Przejdź do akapitu „Tworzenie „grubych” sterowników” (strona 60). n Przy korzystaniu ze wzorca polecenia (Command [GoF]) kod sterowania mo na równie wyodrębnić w obiektach poleceń skoordynowanych ze sterownikiem. n Przejdź do akapitów „Sterownik frontalny” (strona 146). Przykład Załó my, e wiele stron JSP przykładowej aplikacji ma strukturę taką, jak w listingu 5.1. Listing 5.1. Korzystanie ze sterownika — struktura JSP *6/. $1; EQPVTQNITCPVACEEGUU $1; *6/. W wykropkowanej części listingu znajduje się właściwy kod ka dej strony JSP, którego tu nie pokazano, a który jest ró ny w poszczególnych stronach JSP. Nie zmienia się jednak komponent pomocniczy, zaimplementowany na początku kodu ka dej strony jako dodatkowo zdefiniowany znacznik. Komponent ten odpowiada za kontrolę dostępu do strony. Jest to kontrola typu „wszystko albo nic”, co oznacza, e klient mo e uzyskać całkowity dostęp do strony albo nie uzyskać go w ogóle.

9. Rozdział 5. n Sposoby przebudowy J2EE 79 Aby zmienić strukturę poprzez wprowadzenie sterownika, zgodnie z opisem zamieszczonym w poprzedniej sekcji, nale y usunąć ze stron JSP znacznik EQPVTQNITCPVACEEGUU , poka- zany w listingu 5.1. Funkcję tego znacznika, który do tej pory zawarty był we wszystkich stronach JSP, będzie pełnił scentralizowany sterownik, obsługujący kontrolę dostępu. Listing 5.2 ukazuje fragment kodu sterownika, zaimplementowanego jako serwlet. Listing 5.2. Korzystanie ze sterownika — struktura sterownika KH ITCPV#EEGUU ] FKURCVEJ6Q0GZV8KGY _ GNUG ] FKURCVEJ6Q#EEGUUGPKGF8KGY _ Oczywiście w pewnych sytuacjach komponenty pomocnicze dobrze spełniają rolę kodu sterowania. Je eli na przykład tylko ograniczona liczba stron JSP wymaga tego rodzaju kontroli dostępu, to rozsądnym rozwiązaniem jest u ycie komponentu pomocniczego w postaci dodatkowo zdefiniowanego znacznika na tych wybranych stronach. U ycie dodatkowo definio- wanych znaczników w poszczególnych stronach JSP jest równie uzasadnione, gdy chcemy kontrolować dostęp do określonych podwidoków widoku zło onego (przejdź do akapitu „Widok zło ony” w rozdziale 7.). Nawet je eli korzystamy ju ze sterownika, warto rozwa yć zastosowanie omawianego tu rozwiązania scentralizowanego, poniewa liczba stron wymagających takiego zabezpiecze- nia mo e się z czasem zwiększyć. Je eli więc sterownik został ju utworzony, nale y wy- odrębnić z widoków kod sterowania i dodać go do istniejącego sterownika. Oznacza to, e konieczne będzie przeniesienie metod (za pomocą wzorca metody przesunięcia — Move Method [Fowler]), a nie wyodrębnienie nowej klasy. Korzystanie z synchronizatora ądania dostępu do zasobów, wysyłane przez klientów, wymagają monitorowania i kontroli. Pewnym problemem mo e być powtarzalność takich ądań. Klienci mogą te ądać dostępu do pewnych widoków w ró nej kolejności, powracając do poprzednio odwiedzanych, zazna- czonych stron. Skorzystanie z synchronizatora (ang. synchronizer token) umo liwia kontrolę przepływu ądań oraz dostępu klientów do określonych zasobów. Motywacja Istnieje szereg sytuacji, które wymagają kontrolowania przychodzących ądań. Są to najczę- ściej ądania wysyłane powtórnie przez klienta. Powtórzenie ądania ma miejsce na przykład wtedy, gdy u ytkownik kliknie w przeglądarce przycisk Wstecz lub Zatrzymaj i ponownie prześle dany formularz.

10. 80 Część II n Elementy projektów, niewłaściwe techniki oraz przebudowa systemu Rysunek 5.2. Korzystanie z synchronizatora Chocia chodzi tu głównie o sterowanie kolejnością i przepływem ądań, nale y równie wspomnieć o zagadnieniach kontroli dostępu opartej na zezwoleniach. U ycie kontroli dostępu opartej na zezwoleniach omówiono w podrozdziale „Ukrywanie zasobów przed klientem”. Mechanika n Nale y utworzyć jedną lub więcej klas pomocniczych, obsługujących generowanie i porównywanie jednorazowych, unikatowych synchronizatorów. n Rozwiązanie to mo na równie dołączyć do istniejących komponentów sterowania. n Za pomocą takich obiektów pomocniczych komponent zarządzający ądaniami (zazwyczaj jest to sterownik, ale mo e to równie być strona JSP) obsługuje tymczasowe przechowywanie aktualnego synchronizatora dla ka dego ądania przesyłanego przez klienta. n Kopię synchronizatora przechowuje dla ka dego u ytkownika zarówno serwer, jak te przeglądarka klienta. Przeglądarka przechowuje synchronizator zazwyczaj w postaci ukrytego pola, a serwer w sesji u ytkownika. Generowanie, zachowywanie i porównywanie synchronizatorów Zanim odebrane żądanie zostanie przetworzone, sprawdzana jest zgodność synchronizatora. Po prze- tworzeniu żądania generowany i zapisywany jest nowy synchronizator. Dopiero wtedy odpowiedź zostaje przygotowana i odesłana do klienta. Dalsze informacje na ten temat zawiera podrozdział „Korzystanie z synchronizatora” oraz rysunek 5.3. Rysunek 5.3. Cykl „życia” synchronizatora

11. Rozdział 5. n Sposoby przebudowy J2EE 81 n Dołącz kod sprawdzający, czy synchronizator, przesyłany wraz z ądaniem klienta, odpowiada synchronizatorowi sesji u ytkownika. n Wartość synchronizatora przesyłanego przez klienta w bie ącym ądaniu powinna być taka sama, jak wartość synchronizatora, który serwer przesłał do klienta w ostatniej odpowiedzi. Zgodność tych dwóch wartości daje gwarancję, e ądanie nie zostało powtórnie przesłane, podczas gdy brak zgodności mo e oznaczać, e miało miejsce powtórzenie ądania. n Jak ju wspomniano, mo liwe są równie inne przyczyny braku zgodności tych wartości — u ytkownik mógł na przykład udać się bezpośrednio na odwiedzoną wcześniej, zaznaczoną stronę. Najczęstszym jednak powodem pozostaje powtórne przesłanie ądania. Klasa sterownika zazwyczaj obsługuje generowanie oraz porównywanie synchronizatorów. Je eli aplikacja nie posiada sterownika, to warto rozwa yć jego utworzenie. n Zobacz „Korzystanie ze sterownika” na stronie 77. n W przypadku braku sterownika centralnie obsługującego generowanie i porównywanie synchronizatorów konieczne jest zapewnienie takiej obsługi z poziomu ka dej strony JSP. n Zazwyczaj strony JSP wykorzystują w tym celu komponent pomocniczy, zaimplementowany w postaci obiektu JavaBean lub dodatkowo zdefiniowanego znacznika (zobacz „Pomocnik widoku” — strona 157), który zapewnia odpowiednie zarządzanie synchronizatorami. Fragmenty kodu źródłowego, przedstawione w sekcji „Korzystanie z synchronizatora”, zostały u yte zgodnie z warunkami licencji Apache Software License, Version 1.1. Przykład W szkielecie warstwy prezentacji Struts zastosowano kilka wzorców i sposobów przebudowy J2EE, między innymi omawiany tu rodzaj kontroli przepływu ądań. W poni szym przykładzie wykorzystamy fragmenty kodu źródłowego tego szkieletu. W szkielecie Struts nie jest tworzona oddzielna klasa, obsługująca generowanie i porówny- wanie synchronizatorów — funkcjonalność ta jest dodana do utworzonej wcześniej klasy, która stanowi część mechanizmu sterowania szkieletu. Jest to klasa o nazwie #EVKQP („działanie”), będąca wspólną klasą nadrzędną wszystkich działań. Działania są obiektami typu %QOOCPF („polecenie”), stanowiącymi rozszerzenie funkcjonalności sterownika. Jest to aplikacja zgodna ze wzorcem sterownika frontalnego oraz strategią sterownika i polecenia. Listing 5.3 pokazuje, w jaki sposób metoda UCXG6QMGP , zdefiniowana w klasie #EVKQP , generuje i zachowuje wartości synchronizatorów. Listing 5.3. Generowanie i zachowywanie synchronizatorów

14. CRKUCPKG U[PEJTQPKCVQTC PQYGL VTCPUCMELK

15. Y DKG æEGL UGULK W [VMQYPKMC 9 TCKG

16. RQVTGD[ VYQTQPC LGUV PQYC UGULC

17. 82 Część II n Elementy projektów, niewłaściwe techniki oraz przebudowa systemu

19. RCTCO TGSWGUV 2TGVYCTCPG æFCPKG UGTYNGVW

20. RTQVGEVGF XQKF UCXG6QMGP *VVR5GTXNGV4GSWGUV TGSWGUV ] *VVR5GUUKQP UGUUKQP TGSWGUVIGV5GUUKQP 5VTKPI VQMGP IGPGTCVG6QMGP TGSWGUV KH VQMGP PWNN UGUUKQPUGV#VVTKDWVG 64#05#%6+10A61-'0A-'; VQMGP _ Copyright © 1999 The Apache Software Foundation. Wszelkie prawa zastrze one. Metoda ta generuje unikatowy synchronizator w oparciu o ID sesji i bie ący czas, a następnie zapisuje uzyskaną w ten sposób wartość w sesji u ytkownika. Jeszcze przed wygenerowaniem kodu HTML dla klienta przesyłającego ądanie, którego powtórzenia chcemy uniknąć (zazwyczaj jest to formularz odsyłany do serwera), w opisany wcześniej sposób ustawiana jest wartość synchronizatora. Wartość ta zostaje ustawiona poprzez wywołanie metody UCXG6QMGP : UCXG6QMGP TGSWGUV Dodatkowo strona JSP, generująca wyświetlany kod HTML, zawiera równie kod, który — przy wykorzystaniu klasy pomocniczej — generuje ukryte pole, zawierające wartość synchronizatora. Dzięki temu strona odsyłana do klienta (zazwyczaj z formularzem odsyła- nym do serwera) zawiera takie ukryte pole: KPRWV V[RG JKFFGP PCOG QTICRCEJGUVTWVUVCINKDJVON61-'0 XCNWG FEGCFGEC Atrybut XCNWG tego ukrytego pola zawiera wartość synchronizatora, wygenerowanego przez metodę UCXG6QMGP . Gdy klient przesyła stronę zawierającą to ukryte pole, sterownik — poprzez obiekt %QOOCPF (będący podklasą klasy #EVKQP) — porównuje wartość synchronizatora w sesji u ytkownika z wartością parametru TGSWGUV, przesyłanego wraz z ukrytym polem strony. Do porównania tych wartości obiekt %QOOCPF wykorzystuje metodę pokazaną w listingu 5.4, a zaczerpniętą z jego klasy nadrzędnej (równie w tym przypadku jest to klasa #EVKQP). Listing 5.4. Sprawdź poprawność synchronizatora

23. YTCEC YCTVQ è EQFG VTWGEQFG LG GNK Y DKG æEGL UGULK W [VMQYPKMC RTGEJQY[YCP[

24. LGUV U[PEJTQPKCVQT VTCPUCMELK MVÎTGIQ YCTVQ è LGUV IQFPC YCTVQ EKæ RTGMCCPæ

25. LCMQ RCTCOGVT TGSWGUV

27. YTCEC YCTVQ è EQFG HCNUGEQFG Y RT[RCFMW CKUVPKGPKC MVÎTGIQ RQPK U[EJ

28. YCTWPMÎY

29. WN

30. NK æFCPKG PKG LGUV RT[RKUCPG FQ CFPGL UGULKNK

31. NK Y UGULK PKG CRKUCPQ CFPGIQ U[PEJTQPKCVQTCNK

32. NK PKG KUVPKGLG RCTCOGVT TGSWGUV CYKGTCLæE[ YCTVQ è U[PEJTQPKCVQTCNK

33. NK YCTVQ è C æEQPGIQ U[PEJTQPKCVQTC VTCPUCMELK TÎ PK UKú QF YCTVQ EK

34. U[PEJTQPKCVQTC VTCPUCMELK RTGEJQY[YCPGL Y UGULK W [VMQYPKMCNK

35. Rozdział 5. n Sposoby przebudowy J2EE 83

36. WN

38. RCTCO TGSWGUV 2TGVYCTCPG æFCPKG UGTYNGVW

39. RTQVGEVGF DQQNGCP KU6QMGP8CNKF *VVR5GTXNGV4GSWGUV TGSWGUV ] 2QDTCPKG U[PEJTQPKCVQTC VTCPUCMELK CRKUCPGIQ Y DKG æEGL UGULK *VVR5GUUKQP UGUUKQP TGSWGUVIGV5GUUKQP HCNUG KH UGUUKQP PWNN TGVWTP HCNUG 5VTKPI UCXGF 5VTKPI UGUUKQPIGV#VVTKDWVG 64#05#%6+10A61-'0A-'; KH UCXGF PWNN TGVWTP HCNUG 2QDTCPKG U[PEJTQPKCVQTC VTCPUCMELK C æEQPGIQ Y DKG æE[O æFCPKW 5VTKPI VQMGP 5VTKPI TGSWGUVIGV2CTCOGVGT %QPVCPVU61-'0A-'; KH VQMGP PWNN TGVWTP HCNUG 5RTCYFGPKG IQFPQ EK QDW YCTVQ EK TGVWTP UCXGFGSWCNU VQMGP _ Copyright © 1999 The Apache Software Foundation. Wszelkie prawa zastrze one. Je eli porównywane wartości są identyczne, to mamy pewność, e dane ądanie nie zostało przesłane powtórnie. Je eli natomiast wartości synchronizatorów są ró ne, pozwala to podjąć odpowiednie czynności obsługi powtórzonych ądań. Wyodrębnienie procedur rozproszonych Procedury komercyjne oraz kod prezentacji (formatowania) są ze sobą przemieszane w po- szczególnych widokach stron JSP. Procedury komercyjne nale y wyodrębnić w jednej lub większej ilości klas pomocniczych, z których będzie korzystać strona JSP lub sterownik. Rysunek 5.4 ukazuje wyodrębnienie procedur komercyjnych z widoku do klas pomocniczych. Rysunek 5.4. Wyodrębnienie procedur rozproszonych: przebudowa wstecz

40. 84 Część II n Elementy projektów, niewłaściwe techniki oraz przebudowa systemu Rysunek 5.5 ukazuje wyodrębnienie logiki komercyjnej z widoku do sterownika, obiektu %QOOCPF oraz klas pomocniczych. Rysunek 5.5. Wyodrębnienie procedur rozproszonych: przebudowa naprzód Motywacja Celem jest zwiększenie przejrzystości i spójności tworzonych aplikacji przy jednoczesnym zmniejszeniu ilości powielanych fragmentów kodu, co zwiększy modularność i mo liwość wielokrotnego wykorzystania kodu aplikacji. Przejrzysta struktura elementów aplikacji pozwala równie na wyraźny podział pracy pomiędzy twórcami kodu formatowania aplikacji WWW a programistami, zajmującymi się procedurami komercyjnymi. Mechanika n W oparciu o wzorce klasy wydobycia (Extract Class [Fowler]) oraz pomocnika widoku nale y utworzyć nowe klasy pomocnicze, przesuwając do nich procedury komercyjne ze stron JSP. n Klasy te nale y udostępnić z poziomu stron JSP. n Przejdź do akapitu „Pomocnik widoku” (strona 157). n Punktem wyjściowym w procesie obsługi ądania mo e być widok, jak to pokazano na diagramie przebudowy wstecz na rysunku 5.4. Przejdź do akapitu. „Widok przekaźnika” (strona 191). n Warto rozwa yć skorzystanie ze sterownika, je eli aplikacja go nie posiada. n Przejdź do akapitu „Korzystanie ze sterownika” na stronie 77. n Jak to przedstawiono na diagramie przebudowy naprzód (rysunek 5.5), sterownik mo e korzystać z obiektu pomocniczego %QOOCPF. n Punktem wyjściowym w procesie obsługi ądania klientów mo e być sterownik, jak to pokazuje diagram przebudowy naprzód. Przejdź do akapitu „Struktura usługa-pracownik” (strona 180).

41. Rozdział 5. n Sposoby przebudowy J2EE 85 Przykład Rozwa my kod, przedstawiony w widoku w listingu 5.5. Jest to strona JSP, zawierająca fragmenty skryptletu oraz kodu procedur komercyjnych. Listing 5.5. Strona JSP zawierająca kod skryptletu JVON JGCF VKVNG .KUVC RTCEQYPKMÎYVKVNG JGCF DQF[ 9[ YKGVNGPKG PCYKUM YU[UVMKEJ RTCEQYPKMÎY FCPGIQ FKC W MVÎT[EJ CTQDMK PKG RTGMTCECLæ RQFCPGIQ NKOKVW 1MTG NGPKG PCY[ FKC W MVÎTGIQ RTCEQYPKE[ OCLæ QUVCè Y[ YKGVNGPK 5VTKPI FGRVKF5VT TGSWGUVIGV2CTCOGVGT %QPUVCPVU4'3A'26+ 1MTG NGPKG NKOKVW CTQDMÎY 5VTKPI UCNCT[5VT TGSWGUVIGV2CTCOGVGT %QPUVCPVU4'3A5#.#4; 9GT[HKMCELC RCTCOGVTÎY ,G GNK Y[UQMQ è CTQDMÎY NWD FKC PKG QUVC [ QMTG NQPG Y[ YKGVNCPC LGUV UVTQPC KPHQTOCELæ Q D úFKG KH FGRVKF5VT PWNN ^^ UCNCT[5VT PWNN ] TGSWGUVUGV#VVTKDWVG %QPUVCPVU#664A/'55#)' $TCM Y[OCICP[EJ RCTCOGVTÎY Y[UWMKYCPKC KC K CTQDMK TGSWGUVIGV4GSWGUVKURCVEJGT GTTQTLUR HQTYCTF TGSWGUV TGURQPUG _ -QPYGTULC RCTCOGVTÎY RQDTCP[EJ LCMQ C EWEJ[ PCMÎY PC V[R[ PWOGT[EPG KPV FGRVKF HNQCV UCNCT[ VT[ ] FGRVKF +PVGIGTRCTUG+PV FGRVKF5VT UCNCT[ (NQCVRCTUG(NQCV UCNCT[5VT _ ECVEJ 0WODGT(QTOCV'ZEGRVKQP G ] TGSWGUVUGV#VVTKDWVG %QPUVCPVU#664A/'55#)' 0KGY C EKYG YCTVQ EK Y[UWMKYCPKC FGRCTVOGPV KF CPF UCNCT[ TGSWGUVIGV4GSWGUVKURCVEJGT GTTQTLUR HQTYCTF TGSWGUV TGURQPUG _

42. 86 Część II n Elementy projektów, niewłaściwe techniki oraz przebudowa systemu 5RTCYFGPKG RQRTCYPQ EK CMTGUW RCTCOGVTÎY KH UCNCT[ ] TGSWGUVUGV#VVTKDWVG %QPUVCPVU#664A/'55#)' 0KGY C EKYG YCTVQ EK Y[UWMKYCPKC FGRCTVOGPV KF CPF UCNCT[ TGSWGUVIGV4GSWGUVKURCVEJGT GTTQTLUR HQTYCTF TGSWGUV TGURQPUG _ J EGPVGT .KUVC RTCEQYPKMÎY Y FKCNG FGRVKF CTCDKCLæE[EJ FQ UCNCT[ J +VGTCVQT GORNQ[GGU PGY 'ORNQ[GGGNGICVG IGV'ORNQ[GGU FGRVKF VCDNG DQTFGT VT VJ +OKú VJ VJ 0CYKUMQ VJ VJ 5VCPQYKUMQ VJ VJ 0WOGT KFGPV[HKMCE[LP[ VJ VJ 1FNKEGPKC QF RQFCVMW VJ VJ 7YCIK PC VGOCV Y[FCLPQ EK VJ VJ 4QEPG CTQDMK VJ VT YJKNG GORNQ[GGUJCU0GZV ] 'ORNQ[GG81 GORNQ[GG 'ORNQ[GG81 GORNQ[GGUPGZV NKUVC RTCEQYPKMÎY QUVCPKG Y[ YKGVNQPC LG GNK QMTG NQPQ RQRTCYPG MT[VGTKC Y[UWMKYCPKC KH GORNQ[GGIGV;GCTN[5CNCT[ UCNCT[ ] VT VF GORNQ[GGIGV(KTUV0COG VF VF GORNQ[GGIGV.CUV0COG VF VF GORNQ[GGIGVGUKIPCVKQP VF VF GORNQ[GGIGV+F VF VF GORNQ[GGIGV0Q1HGFWEVKDNGU VF VF GORNQ[GGIGV2GTHQTOCPEG4GOCTMU VF VF GORNQ[GGIGV;GCTN[5CNCT[ VF VT _ _ VCDNG

43. Rozdział 5. n Sposoby przebudowy J2EE 87 KPENWFG HKNG LURVTCEGLUR 2 $ 2TQEGFWT[ MQOGTE[LPG QTC MQF HQTOCVQYCPKC YCTUVYC RTGGPVCE[LPC Uæ RTGOKGUCPG Y V[O YKFQMW ,52 $ DQF[ JVON Przedstawiony powy ej kod JSP generuje tabelę HTML, zawierającą listę pracowników o określonych zarobkach. Zawarto tu zarówno procedury komercyjne, jak te kod formatowania, co zilustrowano na rysunku 5.6. Rysunek 5.6. Widok, w którym przemieszano logikę komercyjną z kodem formatowania W listingu 5.6 pokazano, w jaki sposób w oparciu o wzorzec pomocnika widoku mo na zmienić strukturę tak, aby wyodrębnić kod skryptletu z widoku JSP. Listing 5.6. Strona JSP po wyodrębnieniu kodu skryptletu VCINKD WTK 9'$+0(EQTGRCVVGTPUVCINKDTCT[VNF RTGHKZ EQTGRCVVGTPU JVON JGCF VKVNG .KUVC RTCEQYPKMÎYVKVNG JGCF DQF[ EQTGRCVVGTPUGORNQ[GG#FCRVGT J EGPVGT .KUVC RTCEQYPKMÎY FKC W EQTGRCVVGTPUFGRCTVOGPV CVVTKDWVG KF RT[M CF W [EKC QDKGMVW RQOQEPKEGIQ Y FQFCVMQYQ FGHKPKQYCP[O PCEPKMW J VCDNG DQTFGT VT VJ +OKú VJ VJ 0CYKUMQ VJ VJ 5VCPQYKUMQ VJ VJ 0WOGT KFGPV[HKMCE[LP[ RTCEQYPKMC VJ VJ 1FNKEGPKC QF RQFCVMW VJ VJ 7YCIK PC VGOCV Y[FCLPQ EK VJ VJ 4QEPG CTQDMK VJ VT EQTGRCVVGTPUGORNQ[GGNKUV KF GORNQ[GGNKUVAMG[ VT VF EQTGRCVVGTPUGORNQ[GG CVVTKDWVG (KTUV0COG VF VF EQTGRCVVGTPUGORNQ[GG CVVTKDWVG .CUV0COG VF VF EQTGRCVVGTPUGORNQ[GG CVVTKDWVG GUKIPCVKQP VF VF EQTGRCVVGTPUGORNQ[GG CVVTKDWVG +F VF

44. 88 Część II n Elementy projektów, niewłaściwe techniki oraz przebudowa systemu VF EQTGRCVVGTPUGORNQ[GG CVVTKDWVG 0Q1HGFWEVKDNGU VF VF EQTGRCVVGTPUGORNQ[GG CVVTKDWVG 2GTHQTOCPEG4GOCTMU VF VF EQTGRCVVGTPUGORNQ[GG CVVTKDWVG ;GCTN[5CNCT[ VF VF VT EQTGRCVVGTPUGORNQ[GGNKUV VCDNG DQF[ JVON Poza tym zdefiniowano dwa obiekty pomocnicze, zaimplementowane w dodatkowo zdefiniowanych znacznikach, co pozwoliło na wyodrębnienie procedur komercyjnych oraz formatowania poprzez oparcie modelu danych na kolumnach i wierszach tabeli HTML. Dwa obiekty pomocnicze, o których mowa, to znaczniki EQTGRCVVGTPUGORNQ[GGNKUV oraz EQTGRCVVGTPUGORNQ[GG . Rysunek 5.7 ukazuje transformację projektu: od struktury pokazanej po lewej stronie do struktury pokazanej po prawej stronie. Rysunek 5.7. Wyodrębnienie logiki komercyjnej w klasach pomocniczych Procedury komercyjne zostały wyodrębnione w klasach pomocniczych, dzięki czemu nie znajdują się ju bezpośrednio na stronie JSP. Klasy te pełnią szereg funkcji, takich jak po- bieranie określonej zawartości, kontrolowanie dostępu, oraz wyświetlanie stanu modelu dla u ytkownika. W przypadku ostatniej z wymienionych funkcji klasa pomocnicza hermetyzuje część logiki prezentacji, np. formatowanie zbioru wyniku zapytania w postaci tabeli HTML (zobacz tak e „Usuwanie konwersji z widoku”). Takie rozwiązania pozwalają spełnić po- stawiony wcześniej cel wyodrębnienia jak największej części logiki programowania z widoku. Dzięki temu z poziomu JSP mo liwe jest, poprzez u ycie klas pomocniczych, uzyskanie tabeli z określonymi danymi w miejsce kodu skryptletu generującego taką tabelę, zamieszczanego w kodzie JSP. Komponenty pomocnicze mo na implementować w postaci obiektów JavaBean lub te jako dodatkowo definiowane znaczniki (przejdź do akapitu „Pomocnik widoku” w rozdziale 7.). Komponenty pomocnicze JavaBean sprawdzają się najlepiej przy wyodrębnianiu logiki po- bierania zadanej zawartości oraz przechowywania wyników zapytań. Natomiast dodatkowo zdefiniowanych znaczników nale y u ywać do omówionej powy ej konwersji modelu przy wyświetlaniu wyniku, czyli na przykład przy tworzeniu tabeli z zwróconego zbioru wyniku. Obie te opcje mają ze sobą wiele wspólnego, więc wybór techniki implementacji komponen- tów pomocniczych będzie zale ał od doświadczenia programisty i względów praktycznych. Rysunek 5.8 ilustruje drugi punkt podrozdziału „Mechanika”, czyli przekazywanie zadań do klas pomocniczych z poziomu JSP.

45. Rozdział 5. n Sposoby przebudowy J2EE 89 Rysunek 5.8. Przekazywanie zadań do klas pomocniczych Z poziomu widoku JSP wywoływane są klasy pomocnicze, które odpowiadają za przetwa- rzanie i generowanie widoku. Zazwyczaj przed stroną JSP u ywany jest sterownik jako punkt wyjściowy w procesie obsługi ądań klientów (przejdź do akapitów „Sterownik frontalny” w rozdziale 7. oraz „Korzystanie ze sterownika”). Sterownik udostępnia widok, ale zanim do tego dojdzie, mo e równie przekazać zadania do komponentów pomocniczych (przejdź do akapitu „Struktura usługa-pracownik” w rozdziale 7.). Zmiany w strukturze po zastoso- waniu sterownika przedstawiono na rysunku 5.9. Rysunek 5.9. Korzystanie ze sterownika Ukrycie danych warstwy prezentacyjnej przed warstwą komercyjną Obsługa ądań oraz (lub) związane z obsługą protokołu struktury danych są udostępniane z warstwy prezentacyjnej dla warstwy komercyjnej. Z warstwy komercyjnej nale y usunąć wszystkie referencje do obsługi ądań oraz do struktur danych warstwy prezentacyjnej, związanych z obsługą protokołu. Wartości nale y przekazywać pomiędzy warstwami za pomocą ogólnych struktur danych. Rysunek 5.10. Wyodrębnienie kodu warstwy prezentacji z warstwy komercyjnej Motywacja Fragmenty kodu implementacji właściwe dla jednej warstwy nie powinny być umieszczane w innej warstwie. Interfejs API usługi, udostępniany przez warstwę komercyjną warstwie prezentacyjnej, będzie najprawdopodobniej wykorzystywany przez ró nych klientów. Je eli

46. 90 Część II n Elementy projektów, niewłaściwe techniki oraz przebudowa systemu API usługi przyjmuje parametry szczegółowego typu, np. HttpServletRequest, to ka dy klient będzie musiał hermetyzować dane w strukturach danych typu HttpServletRequest. To z kolei radykalnie zmniejsza mo liwość wielokrotnego wykorzystania danej usługi. Mechanika n Wszystkie referencje do struktur danych warstwy prezentacji, zamieszczone w warstwie komercyjnej, nale y zastąpić referencjami do bardziej ogólnych struktur i typów danych. n Chodzi tu zazwyczaj o zastąpienie metod warstwy komercyjnej przyjmujących parametry szczegółowego typu, np. HttpServletRequest, parametrami bardziej ogólnych typów, takich jak String, int czy te UserInfo. n W warstwie prezentacji nale y zmodyfikować kod kliencki, który zawiera wywołania takich metod. n Do metod warstwy komercyjnej mo na przesyłać rozdrobnione struktury danych warstwy prezentacji. Je eli na przykład obiekt ądania HttpServletRequest ma parametry Z, [ oraz , to metoda w warstwie komercyjnej zamiast parametrów typu HttpServletRequest mo e przyjmować te trzy argumenty oddzielnie — jako parametry typu 5VTKPI. Wadą takiego przesyłania rozdrobnionych argumentów jest to, e technika ta zwiększa powiązania pomiędzy kodem warstwy prezentacji a API serwisu komercyjnego. Oznacza to, e przy zmianie stanu wymaganego przez usługę musi równie zostać zmieniony API serwisu. n Nieco bardziej elastyczne rozwiązanie polega na skopiowaniu odpowiedniego stanu ze struktury danych warstwy prezentacji do bardziej ogólnych struktur danych, na przykład do obiektów przyjmujących wartość, które są potem przekazywane do warstwy komercyjnej. W takim przypadku API serwisu nadal przyjmuje obiekt tego typu, nawet je eli zmieniła się jego implementacja. n Inne rozwiązanie polega na implementacji strategii nało enia typu interfejsu, je eli na przykład zastosowano szkielet warstwy prezentacji taki, jak często stosowany projekt Struts [Struts]. n Podczas obsługi ądania szkielety warstwy tworzą zazwyczaj szereg struktur danych. Polega to na przykład na tym, e szkielet kopiuje odpowiedni stan ze struktury danych typu HttpServletRequest do bardziej ogólnych struktur danych, dopasowując parametry ądania do typu danych właściwego dla określonego szkieletu. Chocia wspomniany typ danych mo e spełniać taką samą funkcję, jaką spełnia obiekt posiadający wartość (typu ogólnego), to jednak jest to typ właściwy dla danego szkieletu. Oznacza to, e przesyłanie takiej struktury danych do warstwy komercyjnej wymaga wytworzenia ścisłej zale ności pomiędzy szkieletem obsługującym ądania a serwisami komercyjnymi. Pewnym rozwiązaniem mo e być w tej sytuacji właśnie skopiowanie struktury danych właściwej dla szkieletu do bardziej ogólnej struktury, przed przekazaniem jej do warstwy komercyjnej. Bardziej wydajne jest jednak utworzenie ogólnego typu interfejsu, który będzie zawierał metody odpowiadające metodom typu właściwego dla szkieletu. Nało enie takiego typu interfejsu na obiekt właściwy

47. Rozdział 5. n Sposoby przebudowy J2EE 91 dla szkieletu umo liwi korzystanie z tego obiektu bez konieczności wytwarzania ścisłego powiązania z określonym szkieletem. n Je eli na przykład szkielet tworzy instancję podklasy obiektu CHTCOGYQTM/[5VCVG$GCP, to będzie ona typu 5VCVG$GCP: 7YCIC VYQTGPKG KPUVCPELK QFD[YC UKú CY[ECL RQRTG RTGDWFQYú 7YCIC FNC WRTQUEGPKC RQOKPKúVQ RCTCOGVT[ CHTCOGYQTM5VCVG$GCP DGCP PGY O[UVWHH/[5VCVG$GCP n Gdyby warstwa komercyjna przyjmowała przedstawiony komponent JavaBean jako parametr, byłby on typu 5VCVG$GCP: RWDNKE XQKF C4GOQVG$K6KGT/GVJQF CHTCOGYQTM5VCVG$GCP DGCP n Zamiast przekazywać komponent JavaBean typu 5VCVG$GCP do warstwy komercyjnej, nale y utworzyć nowy interfejs, np. o nazwie my.stuff.MyStateVO, zaimplementowany przez obiekt O[UVWHH/[5VCVG$GCP: RWDNKE ENCUU /[5VCVG$GCP GZVGPFU CHTCOGYQTM5VCVG$GCP KORNGOGPVU /[5VCVG81 n W ten sposób w warstwie komercyjnej mo na u yć następującej sygnatury metody: RWDNKE XQKF C4GOQVG$K6KGT/GVJQF O[UVWHH/[5VCVG81 DGCP n Nie ma potrzeby kopiowania parametrów do obiektu ogólnego typu, posiadającego wartość, a typ właściwy dla szkieletu nie jest ju udostępniany w ró nych warstwach jednocześnie. n Nale y wreszcie zaznaczyć, e zale ności pomiędzy logicznie niezwiązanymi ze sobą częściami mo na zredukować poprzez zastosowanie opisywanego tu sposobu przebudowy dla obiektów warstwy prezentacyjnej. n Ilustracja podobnego przykładu znajduje się na rysunku 5.11. Rysunek 5.11. Oddzielenie kodu warstwy prezentacji od obiektów domeny n Poniewa nale y zachowywać mo liwość wielokrotnego u ycia obiektów rodzimych, takich jak %WUVQOGT, równie w tym przypadku obowiązuje opisywana powy ej motywacja i mechanika. n Oznacza to, e referencje do struktur danych związanych z protokołem są skoncentrowane wokół komponentów obsługujących ądania, takich jak sterownik. Listingi 5.7 oraz 5.8, zamieszczone poni ej, pokazują, w jaki sposób mo na oddzielić obiekt *VVR5GTXNGV4GSWGUV od obiektu rodzimego.

48. 92 Część II n Elementy projektów, niewłaściwe techniki oraz przebudowa systemu Przykład Przedstawiona w listingu 5.7 klasa %WUVQOGT przyjmuje jako parametr instancję obiektu domeny *VVR5GTXNGV4GSWGUV, którego typ charakteryzuje się wysokim stopniem specjalizacji. Oznacza to, e klient spoza Internetu, który chce skorzystać z klasy %WUVQOGT, musiałby najpierw utworzyć w jakiś sposób obiekt *VVR5GTXNGV4GSWGUV, a takich rozwiązań nale y unikać. Listing 5.7. Ścisłe powiązanie obiektu domeny z obiektem HttpServletRequest

50. 2QPK U[ HTCIOGPV MQFW WMCWLG QDKGMV TQFKO[ MVÎT[ QUVC D[V EK NG RQYKæCP[ QDKGMVGO *VVR5GTXNGV4GSWGUV

52. RWDNKE ENCUU %WUVQOGT ] RWDNKE %WUVQOGT *VVR5GTXNGV4GSWGUV TGSWGUV ] HKTUV0COG TGSWGUVIGV2CTCOGVGT HKTUVPCOG NCUV0COG TGSWGUVIGV2CTCOGVGT NCUVPCOG _ _ Zamiast udostępniać obiekt typu HttpServletRequest ogólnemu obiektowi %WUVQOGT, nale y je od siebie oddzielić, jak to pokazano w listingu 5.8. Listing 5.8. Oddzielenie obiektu domeny od obiektu HttpServletRequest 2T[M CF QFFKGNGPKC QDKGMVW FQOGP[ QF QDKGMVW *VVR5GTXNGV4GSWGUV RWDNKE ENCUU %WUVQOGT ] RWDNKE %WUVQOGT 5VTKPI HKTUV 5VTKPI NCUV ] HKTUV0COG HKTUV NCUV0COG NCUV _ _ Usuwanie konwersji z widoku Fragmenty modelu podlegają w komponencie widoku konwersji, która umo liwia ich wy- świetlenie. Cały kod konwersji nale y usunąć z widoku, umieszczając go w jednej lub większej ilości klas pomocniczych. Rysunek 5.12. Usunięcie konwersji z widoku

53. Rozdział 5. n Sposoby przebudowy J2EE 93 Motywacja Bezpośrednie osadzenie w widoku JSP kodu dokonującego konwersji modelu w celu jego wyświetlenia ogranicza modularność i mo liwość wielokrotnego wykorzystywania aplikacji. Poniewa tego rodzaju konwersje mogą być konieczne na wielu stronach JSP, kod konwersji w nich umieszczany musiałby się powtarzać, a utrzymanie takich stron polegałoby na pra- cochłonnym wycinaniu i wklejaniu fragmentów kodu. Mechanika n Za pomocą wzorca klasy wydobycia (Extract Class [Fowler]) oraz pomocnika widoku nale y utworzyć klasy pomocnicze i przenieść do nich procedury konwersji z poszczególnych stron JSP. n Przykładem mo e być konwersja zbioru wyników z bazy danych do postaci tabeli HTML, w oparciu o odpowiedni kod aplikacji. n Klasy te nale y udostępnić z poziomu stron JSP, dzięki czemu — w razie potrzeby — mo liwe będzie dokonanie konwersji i adaptacji. n Konwersja jest przeprowadzana przez klasę pomocniczą, wywoływaną z poziomu strony JSP. Przykład W przedstawionym tu przykładzie zajmiemy się procedurą, która przeprowadza konwersję zbioru elementów (zbioru wyników z bazy danych) do postaci tabeli HTML. Jest to w pewnym sensie procedura formatowania, ale chodzi tu równie o kod konwersji, generujący tabelę z modelu pośredniego. Kod takiej dynamicznej konwersji mo e być wielokrotnie wykorzystywany, je eli zostanie zaimplementowany w dodatkowo zdefiniowanych znacznikach, zamiast bezpośrednio w kodzie strony JSP. W listingu 5.9 przedstawiono stronę JSP, w której kodzie bezpośrednio zamieszczono pro- cedurę konwersji. Listing 5.9. Procedura konwersji umieszczona bezpośrednio w widoku JVON JGCF VKVNG .KUVC RTCEQYPKMÎYVKVNG JGCF DQF[ J JGCF EGPVGT .KUVC RTCEQYPKMÎYJ 5VTKPI HKTUV0COG 5VTKPITGSWGUVIGV2CTCOGVGT HKTUV0COG 5VTKPI NCUV0COG 5VTKPITGSWGUVIGV2CTCOGVGT NCUV0COG KH HKTUV0COG PWNN Y TCKG RQVTGD[ RQDTCPG QUVCPæ YU[UVMKG GNGOGPV[ HKTUV0COG

54. 94 Część II n Elementy projektów, niewłaściwe techniki oraz przebudowa systemu KH NCUV0COG PWNN NCUV0COG 'ORNQ[GGGNGICVG GORGNGICVG PGY 'ORNQ[GGGNGICVG +VGTCVQT GORNQ[GGU GORGNGICVGIGV'ORNQ[GGU 'ORNQ[GGGNGICVG#..A'2#46/'065 VCDNG DQTFGT VT VJ +OKú VJ VJ 0CYKUMQ VJ VJ 5VCPQYKUMQ VJ VT YJKNG GORNQ[GGUJCU0GZV ] 'ORNQ[GG81 GORNQ[GG 'ORNQ[GG81 GORNQ[GGUPGZV KH GORNQ[GGIGV(KTUV0COG UVCTVU9KVJ HKTUV0COG GORNQ[GGIGV.CUV0COG UVCTVU9KVJ NCUV0COG ] VT VF GORNQ[GGIGV(KTUV0COG VQ7RRGT%CUG VF VF GORNQ[GGIGV.CUV0COG VQ7RRGT%CUG VF VF GORNQ[GGIGVGUKIPCVKQP VF VT _ _ VCDNG Najpierw taki kod nale y wyodrębnić w klasach pomocniczych. Klasy takie nale y w tym przypadku zaimplementować w dodatkowo zdefiniowanych znacznikach, co umo liwi usu- nięcie mo liwie największej ilości kodu skryptletu ze strony JSP. Następnie w kodzie strony JSP nale y umieścić odwołania do klas pomocniczych, przeprowadzających konwersję. W listingu 5.10 przedstawiono stronę JSP po wprowadzeniu takich zmian. Listing 5.10. Wyodrębnienie procedury w klasach pomocniczych JVON JGCF VKVNG .KUVC RTCEQYPKMÎY RQ RTGDWFQYKG VKVNG JGCF DQF[ J EGPVGT .KUVC RTCEQYPKMÎYJ EQTGRCVVGTPUGORNQ[GG#FCRVGT VCDNG DQTFGT

55. Rozdział 5. n Sposoby przebudowy J2EE 95 VT VJ +OKú VJ VJ 0CYKUMQ VJ VJ 5VCPQYKUMQ VJ VT EQTGRCVVGTPUGORNQ[GGNKUV KF GORNQ[GGNKUV OCVEJ (KTUV0COG .CUV0COG VT VF EQTGRCVVGTPUGORNQ[GG CVVTKDWVG (KTUV0COG ECUG 7RRGT VF VF EQTGRCVVGTPUGORNQ[GG CVVTKDWVG .CUV0COG ECUG 7RRGT VF VF EQTGRCVVGTPUGORNQ[GG CVVTKDWVG GUKIPCVKQP VF VF VT EQTGRCVVGTPUGORNQ[GGNKUV VCDNG Warto te rozwa yć inny rodzaj konwersji. W niektórych przypadkach fragmenty modelu podlegają konwersji do HTML poprzez transformacje XSL. W tym celu równie mo na wy- korzystać klasy pomocnicze, wywoływane za pomocą dodatkowo zdefiniowanych znaczników. Równie takie rozwiązanie pozwala wyodrębnić procedurę ze strony JSP, zwiększając w ten sposób modularność i mo liwość wielokrotnego wykorzystania komponentów. Poni ej uka- zano przykład strony JSP, w której konwersja wykonywana jest poprzez wywołanie za pomocą dodatkowych znaczników klas pomocniczych, a nie bezpośrednio w kodzie strony: VCINKD WTK JVVRLCMCTVCCRCEJGQTIVCINKDUZUN RTGHKZ ZUN ZUNCRRN[ PCOG:ON OQFGN RTQRGTV[:/. ZON ZUN UV[NGUJGGVVTCPUHQTOZUN Znacznik XSL CRRN[ [JakartaTaglibs] odpowiada za wygenerowanie całego wyniku z tej strony. Za jego pomocą mo na utworzyć w podobny sposób poszczególne składniki strony. Wywołanie za pomocą znacznika jest mo liwe, poniewa w zakresie strony („modelu”) istnieje komponent JavaBean z właściwością o nazwie „xml”. Innymi słowy, w zakresie strony znajduje się instancja komponentu, który zawiera metodę o następującej sygnaturze: RWDNKE 5VTKPI IGV:/. Warto zaznaczyć, e tego typu konwersje mo na przeprowadzać całkowicie niezale nie od JSP. Wybór tego rozwiązania będzie zale ał od szeregu czynników, takich jak format przechowywania zawartości oraz u ycie dotychczasowo stosowanych technologii. Ukrywanie zasobów przed klientem Czasami zachodzi potrzeba ograniczenia dostępu klientów do zasobów takich, jak widoki JSP, do których mają oni bezpośredni dostęp. Dostęp do zasobów mo na ograniczyć poprzez skonfigurowanie kontenerów lub u ycie sterownika.

56. 96 Część II n Elementy projektów, niewłaściwe techniki oraz przebudowa systemu Rysunek 5.13. Ograniczenie dostępu poprzez skonfigurowanie kontenerów Rysunek 5.14. Ograniczenie dostępu za pomocą komponentu sterowania Motywacja Często zachodzi potrzeba kontroli przychodzących ądań. Omawiany tu sposób przebudowy umo liwia wprowadzenie opartej na zezwoleniach kontroli i ochrony zasobów. Je eli istnieje potrzeba wprowadzenia kontroli kolejności lub przepływu ądań, nale y zasto- sować rozwiązania omówione w podrozdziale „Korzystanie z synchronizatora” (rozdział 5.). Mechanika n Dostęp do pewnych zasobów (na przykład zasobów WWW, serwletów itp.) nale y ograniczać poprzez odpowiednią konfigurację, polegającą na przeniesieniu takich zasobów do odpowiednich podkatalogów w podkatalogu /WEB-INF/ aplikacji WWW. n Aby na przykład zablokować bezpośredni dostęp przeglądarki do widoku o nazwie info.jsp w aplikacji securityissues, mo na umieścić plik źródłowy JSP w następującym podkatalogu: /securityissues/WEB-INF/internalaccessonly/info.jsp. n Dostęp mo na te ograniczać za pomocą komponentu kontrolnego. n W tym celu mo na wykorzystać wzorzec przedstawiony w sekcji „Korzystanie ze sterownika” (rozdział 5.), gdzie pokazano, w jaki sposób sterownik mo e kontrolować dostęp do chronionych zasobów.

57. Rozdział 5. n Sposoby przebudowy J2EE 97 n Dodatkowo, wszystkie zasoby podlegające ochronie mogą same kontrolować dostęp, wywołując odpowiednie klasy pomocnicze. n Nale y utworzyć jedną lub więcej klas pomocniczych. n W zale ności od implementacji sterownik lub poszczególne strony JSP wywołują klasy pomocnicze, które sprawdzają, czy dany zasób powinien zostać udostępniony. Przykład Ograniczenie dostępu poprzez konfigurację pojemnika Aby dostęp klienta do przykładowej strony JSP info.jsp był mo liwy tylko poprzez sterownik, nale y przenieść stronę JSP do katalogu /WEB-INF/. W przykładowej aplikacji WWW o nazwie corepatterns skonfigurowano następujący katalog w głównym katalogu serwera: EQTGRCVVGTPUUGEWTGARCIGLUR Taka konfiguracja domyślnie umo liwia klientom bezpośredni dostęp do tego zasobu, np. za pomocą poni szego adresu URL: JVVRNQECNJQUVEQTGRCVVGTPUUGEWTGARCIGLUR Aby zastrzec bezpośredni dostęp, nale y przenieść plik JSP do podkatalogu katalogu /WEB-INF/. Ście ka dostępu w głównym katalogu serwera będzie wyglądała wtedy nastę- pująco: EQTGRCVVGTPU9'$+0(RTKXCVGCEEGUUUGEWTGARCIGLUR Zawartość katalogu /WEB-INF/ jest dostępna tylko pośrednio poprzez ądania wewnętrzne, wysyłane na przykład przez sterownik oraz obiekt 4GSWGUVKURCVEJGT. Oznacza to, e adres URL, pod którym przeglądarka mo e uzyskać dostęp do tego pliku, będzie wyglądał mniej więcej następująco: JVVRNQECNJQUVEQTGRCVVGTPUEQPVTQNNGT!XKGYEQTGRCVVGTPU å9'$+0(RTKXCVGCEEGUUUGEWTGARCIGLUR Uwaga: podany powy ej adres URL ilustruje jedynie omawiane zagadnienia i nie stanowi zalecanej metody przekazywania informacji do serwera. Parametr zapytania widoku nie powinien ujawniać struktury katalogów serwera. Je eli ądanie dotarło do sterownika serwletu, to mo e on je przekazać do strony secure_page .jsp, korzystając z obiektu 4GSWGUVKURCVEJGT. Natomiast przy próbie uzyskania bezpośredniego dostępu do zasobu: JVVRNQECNJQUVEQTGRCVVGTPU9'$+0(RTKXCVGCEEGUUUGEWTGARCIGLUR serwer odsyła odpowiedź z informacją o braku dostępu do ądanego zasobu, co pokazano na rysunku 5.15.

58. 98 Część II n Elementy projektów, niewłaściwe techniki oraz przebudowa systemu Rysunek 5.15. Ograniczenie dostępu poprzez odpowiednią konfigurację plików Ograniczenie dostępu poprzez u ycie komponentu kontrolnego Innym sposobem ograniczania dostępu jest wywołanie komponentu kontrolującego, tak jak pokazano to na rysunku 5.14 i w listingu 5.11. Listing 5.11. Kontrola dostępu przy użyciu komponentu VCINKD WTK 9'$+0(EQTGRCVVGTPUVCINKDTCT[VNF RTGHKZ EQTGRCVVGTPU EQTGRCVVGTPUIWCTF JVON JGCF VKVNG 1ITCPKEGPKG FQUVúRW MNKGPVC FQ CUQDÎYVKVNG JGCF DQF[ J -NKGPV W[UMWLG FQUVúR FQ VGIQ YKFQMW V[NMQ C RQ TGFPKEVYGO MQORQPGPVW MQPVTQNPGIQ 9KFQM VGP Y[YQ WLG OGEJCPKO MQPVTQNK FQUVúRW C RQOQEæ PCEPKMC MQPVTQNPGIQ W [VGIQ PC RQEæVMW UVTQP[J DQF[ JVON Sposoby przebudowy warstwy komercyjnej i integracyjnej Zamknięcie komponentów jednostkowych w sesji Komponenty jednostkowe z warstwy komercyjnej są udostępniane klientom w innej warstwie. Komponenty jednostkowe nale y wyodrębnić poprzez u ycie fasady sesji.

59. Rozdział 5. n Sposoby przebudowy J2EE 99 Rysunek 5.16. Zamknięcie komponentów jednostkowych w sesji Motywacja Komponenty jednostkowe (ang. entity beans) to rozproszone, trwałe obiekty ogólnego zastosowania. Udostępnienie komponentu jednostkowego klientom w innej warstwie wywołuje przecią enie sieci i obni enie wydajności. Ka de ądanie klienta oznacza kosztowne pod względem wydajności wywołanie metody odległej. U ycie komponentów jednostkowych oznacza wprowadzenie transakcji zarządzanej przez pojemniki. Udostępnienie komponentu jednostkowego klientom mo e wymagać od programisty aplikacji klienckiej przeanalizowania, zaprojektowania oraz demarkacji transakcji, zwłaszcza w przypadku u ycia wielu komponentów jednostkowych. Programista taki musi uzyskać dostęp do transakcji u ytkownika od obiektu zarządzania transakcjami oraz opraco- wać kod interakcji z komponentami jednostkowymi (interakcja ta ma się odbywać w kontekście transakcji). Poniewa klient zarządza transakcją, nie jest mo liwe wykorzystanie demarkacji transakcji zarządzanej przez pojemniki. Mechanika n Procedury komercyjne, które powinny współdziałać z komponentami jednostkowymi, nale y wyodrębnić z kodu klienta aplikacji. n Do wyodrębnienia procedur z kodu klienta mo na wykorzystać wzorzec klasy wydobycia ('ZVTCEV %NCUU [Fowler]). n Następnie nale y u yć komponentu sesyjnego jako fasady dla jednostki. n Taki komponent sesyjny mo e zawierać procedury interakcji z komponentem jednostkowym oraz inne potrzebne procedury. n Przejdź do akapitu „Fasada sesji”, (rozdział 8.). n Nale y potem zaimplementować komponenty sesyjne w celu utworzenia skonsolidowanej warstwy dostępu do komponentów jednostkowych — w oparciu o wzorzec fasady sesji. n Liczne interakcje pomiędzy klientem a jednostkami zostają w ten sposób przesunięte do fasady sesji w warstwie komercyjnej.

60. 100 Część II n Elementy projektów, niewłaściwe techniki oraz przebudowa systemu n Dzięki temu zredukowana zostaje liczba wywołań metod odległych, dokonywanych przez klienta. n Następnie nale y zaimplementować procedury transakcji w komponentach sesyjnych, je eli u ywane są transakcje zarządzane przez komponenty JavaBean. W przypadku transakcji zarządzanych przez pojemniki nale y określić atrybuty transakcji dla komponentu sesyjnego w obiekcie opisu wdra ania. n Poniewa komponent sesyjny współdziała z komponentami jednostkowymi, klient nie jest ju odpowiedzialny za demarkację transakcji. n Za demarkację transakcji odpowiada teraz albo komponent sesyjny, albo pojemnik — w zale ności od tego, czy wybrano model transakcji zarządzanych przez u ytkownika czy te przez pojemnik. Korzystanie z delegatów komercyjnych Komponenty sesyjne w warstwie komercyjnej są udostępniane klientom w innych warstwach. Za pomocą delegatów komercyjnych nale y rozdzielić warstwy i wyodrębnić szczegóły implementacji. Rysunek 5.17. Użycie delegacji komercyjnej Motywacja Komponenty sesyjne umo liwiają implementację fasad dla komponentów jednostkowych. Komponenty sesyjne pozwalają na utworzenie interfejsów dla ogólnych serwisów komercyjnych. Nale y jednak pamiętać, e bezpośrednie udostępnienie komponentu sesyjnego dla klienta aplikacji wymusza ścisłe powiązania pomiędzy kodem klienta aplikacji a komponentem sesyjnym. Udostępnienie komponentu sesyjnego dla klienta aplikacji zwiększa liczbę wywołań komponentu sesyjnego w kodzie klienta. Ka da zmiana w interfejsie komponentu sesyjnego ma wpływ na wszystkie wywołania komponentu sesyjnego w kodzie klienta aplikacji, co oznacza problemy z utrzymaniem kodu. Przy korzystaniu z komponentów EJB klienci są dodatkowo nara eni na wyjątki, występujące na poziomie usługi. Mo e to być szczególnie kłopotliwe w przypadku aplikacji u ywanej przez ró nego rodzaju klientów, z których ka dy korzysta z interfejsu komponentu sesyjnego w celu uzyskania określonej usługi.

61. Rozdział 5. n Sposoby przebudowy J2EE 101 Mechanika n Dla ka dego komponentu sesyjnego, który jest udostępniany klientom bezpośrednio w warstwie, nale y zastosować delegata komercyjnego. n Delegaci komercyjni to standardowe klasy Javy, w których wyodrębniono szczegóły implementacji warstwy komercyjnej. Klasy te pośredniczą pomiędzy klientami a komponentem sesyjnym, przejmując wyjątki powstające na poziomie obsługi. n Przejdź do akapitu „Delegat komercyjny”, rozdział 8. n Nale y utworzyć delegacje komercyjne, które będą obsługiwały poszczególne komponenty sesyjne, zazwyczaj jako fasady. Ka dej delegacji komercyjnej odpowiada tylko jedna fasada sesji. n Delegaci komercyjni redukują ścisłe powiązania pomiędzy warstwą klienta a serwisami komercyjnymi (komponentami sesyjnymi) poprzez wyodrębnienie szczegółów implementacji. n Klienci współpracują z delegatami komercyjnymi za pomocą lokalnych wywołań znajdujących się w nich metod. n Kod usług wyszukiwania oraz zachowywania w pamięci podręcznej nale y wyodrębnić w delegacjach komercyjnych. n Delegaci komercyjni wyszukują serwisy komercyjne za pomocą lokalizatora usług. n Przejdź do akapitu „Lokalizator usług”, rozdział 8. Łączenie komponentów sesyjnych Pomiędzy komponentami sesyjnymi a komponentami jednostkowymi zachodzi relacja typu „jeden do jednego”. Ogólne serwisy komercyjne nale y odwzorować w komponentach sesyjnych. Komponenty sesyjne, które pełnią tylko rolę obiektów proxy komponentów jednostkowych, nale y wyeliminować lub te połączyć w pojedynczy komponent sesyjny. Rysunek 5.18. Łączenie komponentów sesyjnych

62. 102 Część II n Elementy projektów, niewłaściwe techniki oraz przebudowa systemu Motywacja Relacja typu „jeden do jednego” pomiędzy komponentem sesyjnym a komponentem jednostkowym jest rozwiązaniem niekorzystnym. Takie odwzorowanie wprowadza jedynie warstwę komponentów sesyjnych, pełniących rolę obiektów proxy. Ma to zazwyczaj miejsce wtedy, gdy programista tworzy komponenty sesyjne, które nie stanowią reprezentacji serwisów ogólnego zastosowania, a jedynie wysuwają naprzód komponenty jednostkowe (pośredniczą pomiędzy nimi). W rezultacie komponenty sesyjne nie stanowią fasad, a jedynie obiekty proxy. Wady bezpośredniego udostępniania komponentów jednostkowych klientom omówiono w podrozdziale „Zamknięcie komponentów jednostkowych w sesji”. Na rysunku 5.18 ró ni klienci obsługują ró ne rodzaje interakcji. W ka dej takiej interakcji bierze udział jeden lub więcej komponentów jednostkowych. W przypadku rozwiązania, po- legającego na utworzeniu relacji typu „jeden do jednego” pomiędzy komponentami sesyjnymi a jednostkami, klient współdziała z poszczególnymi komponentami sesyjnymi, które pośred- niczą pomiędzy nim a komponentami jednostkowymi. W takiej sytuacji komponenty sesyjne są obiektami proxy, co oznacza, e klienci mają w zasadzie bezpośredni dostęp do komponen- tów jednostkowych. Mechanika n Komponenty sesyjne nale y zaimplementować jako fasadę komponentów jednostkowych. Dzięki temu ka dy komponent sesyjny będzie zapewniał klientom interfejs serwisu komercyjnego ogólnego zastosowania. n Wyspecjalizowane komponenty sesyjne oraz komponenty sesyjne, stanowiące obiekty proxy dla komponentów jednostkowych, nale y połączyć w pojedynczy komponent sesyjny. n Komponenty sesyjne będą stanowiły reprezentację serwisu komercyjnego ogólnego zastosowania. n Komponenty jednostkowe będą stanowiły reprezentację zachowanych informacji, dotyczących transakcji. n Przejdź do akapitu „Fasada sesji”, rozdział 8. n Aby uniknąć implementacji ka dej interakcji w osobnym komponencie sesyjnym, nale y połączyć zbiór powiązanych ze sobą interakcji, w których bierze udział jeden lub więcej komponentów sesyjnych, w pojedynczą fasadę sesji. n Pozwala to ograniczyć rolę komponentów sesyjnych, umo liwiających dostęp jednolitych serwisów komercyjnych do komponentów jednostkowych. n Liczba fasad sesji powinna zale eć od sposobu pogrupowania interakcji, a nie od liczby jednostek. Ograniczanie komunikacji międzyjednostkowej Wiele zale ności między komponentami jednostkowymi prowadzi do obni enia wydajność modelu.

63. Rozdział 5. n Sposoby przebudowy J2EE 103 Liczbę zale ności pomiędzy komponentami jednostkowymi nale y obni yć poprzez u ycie komponentu jednostkowego (jednostki zło onej) oraz obiektów zale nych. Rysunek 5.19. Ograniczenie komunikacji między komponentami jednostkowymi Motywacja Komponenty jednostkowe pochłaniają du o więcej czasu procesora ni zwykłe obiekty Javy. Wywołania metod jednostek są wywołaniami odległymi, przez co obni ają wydajność sieci. Dodatkowo, komponenty jednostkowe muszą współdziałać z zewnętrznym źródłem danych. Nawet, je eli dane dwa komponenty jednostkowe znajdują się w tym samym pojemniku, w momencie, gdy jeden z nich wywołuje drugi komponent, nadal obowiązuje schemat zdalnych wywołań metod (pojemnik uczestniczy w komunikacji). Co prawda w niektórych implemen- tacjach pojemników zoptymalizowano tego rodzaju wywołania poprzez rozró nianie wywołań pochodzących od obiektów, znajdujących się w tym samym pojemniku, ale nie są to rozwią- zania, które mo na stosować uniwersalnie (obowiązują tylko w określonej grupie produktów danej firmy). Nale y równie pamiętać, e jednostka nie jest w stanie dokonać demarkacji transakcji. W przypadku korzystania z komponentów jednostkowych mo liwe są tylko transakcje za- rządzane przez pojemniki. Oznacza to, e — w zale ności od ustawionego atrybutu transakcji metody w komponencie jednostkowym — pojemnik mo e rozpocząć nową transakcję, wziąć udział w bie ącej transakcji lub te nie wykonać adnej z tych czynności. Kiedy klient wy- wołuje metodę w komponencie jednostkowym, do kontekstu transakcji zostaje włączony szereg jednostek zale nych. Powoduje to obni enie ogólnej wydajności komponentów jednostkowych, poniewa ka da transakcja mo e oznaczać zablokowanie wielu komponentów jednostkowych, a w rezultacie mo e doprowadzić do zakleszczenia. Mechanika n Jednostki nale y zaprojektować jako obiekty ogólnego przeznaczenia, zło one z obiektów głównych i obiektów zale nych. n Relacje międzyjednostkowe nale y zastąpić relacjami typu jednostka — obiekt zale ny. n Obiekty zale ne nie są komponentami jednostkowymi. Są to obiekty, zawierające się w komponencie jednostkowym. Pomiędzy komponentem

64. 104 Część II n Elementy projektów, niewłaściwe techniki oraz przebudowa systemu jednostkowym a znajdującymi się w nim obiektami zale nymi występuje relacja lokalna, która nie obcią a sieci. n Przeprowadzane przez jednostki zło one operacje ładowania oraz przechowywania danych nale y zoptymalizować, korzystając ze wzorców: strategii oszczędnego wczytywania oraz strategii optymalizacji zapisu. n Przejdź do akapitu „Jednostka zło ona”, rozdział 8. n Z komponentu jednostkowego nale y wyodrębnić procedury współdziałania z innymi jednostkami i przenieść je do komponentu sesyjnego. n W oparciu o wzorzec metody wydobycia ('ZVTCEV /GVJQF [Fowler]) i (lub) metody przesunięcia (/QXG /GVJQF [Fowler]) nale y przenieść taką procedurę komercyjną do komponentu sesyjnego, stosując w tym celu wzorzec fasady sesji. n Przejdź do akapitu „Fasada sesji”, rozdział 8. Przesunięcie procedur komercyjnych do sesji Du a liczba zale ności pomiędzy jednostkami obni a wydajność modelu. Operacje związane z zale nościami pomiędzy komponentami jednostkowymi nale y wyodrębnić w komponencie sesyjnym (tworząc fasadę sesji). Rysunek 5.20. Przesunięcie procedur komercyjnych do sesji Motywacja W podrozdziale „Ograniczanie komunikacji międzyjednostkowej” omówiono problemy związane z bezpośrednimi zale nościami między komponentami jednostkowymi. Problemy te wynikały z faktu, i komponent jednostkowy mo e zawierać procedury komercyjne, które zostały utworzone do obsługi innych komponentów jednostkowych. Takie rozwiązanie wymusza bezpośrednie i pośrednie zale ności z innymi jednostkami. Problemy omawiane w powy szym podrozdziale mają równie zastosowanie tutaj.

65. Rozdział 5. n Sposoby przebudowy J2EE 105 Mechanika n Procedury komercyjne, związane z interakcją między jednostkami, nale y przenieść z komponentu jednostkowego do komponentu sesyjnego. n W oparciu o wzorzec metody wydobycia ('ZVTCEV /GVJQF [Fowler]) i (lub) metody przesunięcia (/QXG /GVJQF [Fowler]) nale y przenieść procedury komercyjne do komponentu sesyjnego, z zastosowaniem wzorca fasady sesji. n Przejdź do akapitu „Fasada sesji”, rozdział 8. n Przejdź do akapitu „Zamknięcie komponentów jednostkowych w sesji”, rozdział 5. Ogólne sposoby przebudowy Separacja kodu dostępu do danych Kod dostępu do danych jest umieszczany bezpośrednio w klasach, które obsługują operacje niezwiązane z dostępem do danych. Kod dostępu do danych nale y wyodrębnić w nowej klasie, którą następnie nale y przesunąć logicznie i (lub) fizycznie bli ej źródła danych. Rysunek 5.21. Separacja kodu dostępu do danych Motywacja Tworząc aplikacje, nale y zadbać o ich przejrzystą strukturę oraz spójność. Jednocześnie nale y unikać zbyt ścisłych zale ności pomiędzy ró nymi komponentami, zwiększając w ten sposób ich modularność oraz mo liwość wielokrotnego wykorzystania. Mechanika n Procedury dostępu do danych nale y wydzielić z obiektu sterowania. n W oparciu o wzorzec klasy wydobycia ('ZVTCEV %NCUU [Fowler]) nale y utworzyć nową klasę obiektu dostępu do danych i przenieść do niej kod dostępu z określonej klasy. n W nazwie utworzonej w ten sposób klasy warto zaznaczyć, e jest to obiekt dostępu do danych.

J2EE. Wzorce projektowe

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to J2EE. Wzorce projektowe

Similar to J2EE. Wzorce projektowe (20)

More from Wydawnictwo Helion

More from Wydawnictwo Helion (20)

J2EE. Wzorce projektowe