[ Pobierz całość w formacie PDF ]
JnriObjectFactoryBean zwraca obiekt będący wynikiem operacji wyszukiwania JNDI.
ProxyFactoryBean opakowuje istniejący obiekt wewnątrz odpowiedniego
pośrednika, który jest następnie zwracany w odpowiedzi na żądanie. Rzeczywiste
funkcjonowanie tego pośrednika zależy od konfiguracji zdefiniowanej przez
użytkownika może obejmować przechwytywanie i modyfikowanie zachowania
obiektu, przeprowadzanie testów bezpieczeństwa itd. Techniki stosowania tego
komponentu fabrykującego omówimy bardziej szczegółowo w rozdziale poświęconym
frameworkowi programowania aspektowego (AOP) oferowanemu w ramach Springa.
TransactionProxyFactoryBean specjalizacja klasy ProxyFactoryBean,
która opakowuje obiekt transakcyjnym pośrednikiem.
Rozdział 2. Fabryka komponentów i kontekst aplikacji 121
RmiProxyFactoryBean tworzy pośrednik obsługujący przezroczysty dostęp do
zdalnego obiektu za pośrednictwem technologii zdalnego wywoływania metod
(RMI). Podobne obiekty pośredniczące, tyle że dla dostępu do zdalnych obiektów
przez protokoły HTTP, JAX-RPC, Hessian i Burlap są tworzone odpowiednio
przez klasy HttpInvokerProxyFactoryBean, JaxRpcPortProxyFactoryBean,
HessianProxyFactoryBean i BurlapProxyFactoryBean. We wszystkich przypadkach
klient nie musi dysponować żadną wiedzą o pośredniku wystarczy przystosowanie
do współpracy z interfejsem biznesowym.
LocalSessionFactoryBean konfiguruje i zwraca obiekt SessionFactory
frameworka Hibernate. Istnieją podobne klasy także dla innych mechanizmów
zarządzania zasobami, w tym JDO i iBatis.
LocalStatelessSessionProxyFactoryBean i SimpleRemoteStatelessSessionProxyFactoryBean
tworzą obiekt pośrednika wykorzystywany do uzyskiwania dostępu odpowiednio
do lokalnych lub zdalnych bezstanowych komponentów sesyjnych EJB. Sam klient
wykorzystuje tylko interfejs biznesowy (bez konieczności obsługi dostępu do JNDI
lub interfejsów EJB).
MethorInvokingFactoryBean zwraca wynik wywołania metody innego
komponentu, natomiast klasa FielrRetrievingFactoryBean zwraca wartość pola
należącego do innego komponentu.
Wiele komponentów fabrykujących związanych z technologią JMS zwraca jej zasoby.
Podsumowanie i efekt końcowy
W poprzednich punktach przekonaliśmy się, że konfigurowanie obiektów z wykorzystaniem
technik IoC jest bardzo proste. Zanim jednak przystąpimy do wzajemnego wiązania obiek-
tów, musimy te obiekty najpierw utworzyć lub uzyskać. W przypadku kilku potencjalnych
obiektów współpracujących (nawet jeśli są ostatecznie udostępniane i konfigurowane za
pośrednictwem standardowego interfejsu) sam fakt tworzenia i uzyskiwania rozmaitych
obiektów za pomocą skomplikowanych i niestandardowych mechanizmów może stanowić
przeszkodę w efektywnym przetwarzaniu obiektów. Okazuje się, że można tę przeszkodę
wyeliminować za pomocą komponentów fabrykujących. Po początkowych fazach tworze-
nia i wiązania obiektów produkty generowane przez komponenty fabrykujące (osadzane
w pośrednikach i innych podobnych obiektach opakowań) mogą pełnić funkcję adaptera
mogą pomagać w budowie abstrakcji ponad rzeczywistymi zasobami i usługami oraz za-
pewniać dostęp do zupełnie niepodobnych usług za pośrednictwem podobnych interfejsów.
Jak wiemy, zródła danych można dowolnie wymieniać bez konieczności umieszczania
w kodzie klienta (w analizowanym przykładzie tę funkcję pełnił obiekt weatherDao) jakich-
kolwiek zapisów uzależniających od stosowanej technologii przykładowo, zastąpiliśmy
oryginalną implementację interfejsu DataSource opartą na Commons DBCP (mającą postać
lokalnego komponentu) implementacją interfejsu DataSource właściwą dla technologii JNDI.
Taka zamiana jest możliwa nie tylko dzięki mechanizmowi IoC, ale także dzięki wyprowa-
dzeniu operacji dostępu do zasobów poza kod aplikacji i tym samym przygotowaniu
właściwej struktury dla technik IoC.
122 Spring Framework. Profesjonalne tworzenie oprogramowania w Javie
Mamy nadzieję, że dostrzegasz dwie najważniejsze zalety omawianego mechanizmu
z jednej możliwość łatwego abstrahowania od usług i zasobów, z drugiej strony możli-
wość wymiany jednego rozwiązania na inne bez konieczności wykorzystywania sposo-
bów wdrożenia i technologii, których stosowanie podczas budowy wielu aplikacji naj-
zwyczajniej w świecie mija się z celem. Cechą wyróżniającą Springa jest niezależność
kodu klienta zarówno od faktycznego wdrożenia, jak i od użytego sposobu implementacji.
Skoro możemy w sposób transparentny, przezroczysty (przynajmniej z perspektywy klien-
ta) uzyskiwać dostęp do zdalnych usług za pośrednictwem takich technologii jak RMI,
RPC przez HTTP czy EJB, niby dlaczego nie mielibyśmy wdrażać całkowicie niezależnych
rozwiązań, i po co w ogóle wiązać kod klienta z jedną implementacją ponad inną tam, gdzie
nie jest to konieczne? W rozwiązaniach platformy J2EE można zaobserwować tendencję do
udostępniania takich zasobów jak implementacje DataSource, zasoby JMS czy interfejsy
JavaMail za pośrednictwem JNDI. Nawet jeśli ten sposób udostępniania zasobów znajduje
jakieś uzasadnienie, bezpośredni dostęp klienta do środowiska JNDI jest całkowicie sprzeczny
z założeniami efektywnego wytwarzania oprogramowania. Budowa dodatkowej warstwy
abstrakcji np. za pomocą klasy JnriObjectFactoryBean oznacza, że w przyszłości będzie
można zmienić środowisko na inne niż JNDI bez konieczności modyfikowania kodu
klienta (odpowiednio dostosowując wyłącznie konfigurację samej fabryki komponentów).
Nawet jeśli nie planujesz zmiany środowiska wdrożeniowego ani technologii implementa-
cji już po wdrożeniu oprogramowania w docelowym środowisku, możesz być pewien, że
taka abstrakcja znacznie ułatwi testy jednostkowe i testy integracyjne, ponieważ umożliwi
weryfikację różnych konfiguracji wdrożeń i scenariuszy testowych. Tym zagadnieniom po-
[ Pobierz całość w formacie PDF ]