[ Pobierz całość w formacie PDF ]
Rozdział 2. Fabryka komponentów i kontekst aplikacji 97
Równie dobrze moglibyśmy użyć egzemplarza InputStream:
InputStream is = new FileInputStream("/some/file/path/beans.xml");
XmlBeanFactory factory = new XmlBeanFactory(is);
Aby wyczerpać ten temat, musimy wspomnieć o możliwości prostego oddzielenia operacji
tworzenia fabryki komponentów od procesu przetwarzania definicji komponentów. Nie bę-
dziemy się zajmować tym zagadnieniem w szczegółach, warto jednak pamiętać, że takie
wyodrębnienie zachowania fabryki komponentów od mechanizmów przetwarzania definicji
komponentów upraszcza stosowanie innych formatów konfiguracji:
ClassPathResource res = new ClassPathResource("beans.xml"});
DefaultListableBeanFactory factory = new DefaultListableBeanFactory();
XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(factory);
reader.loadBeanDefinitions(res);
Stosując klasę GenericApplicationContext dla kontekstu aplikacji, możemy w podobny
sposób oddzielić kod tworzący ten kontekst od kodu przetwarzającego definicje kompo-
nentów. Wiele aplikacji Springa w ogóle nie tworzy kontenera programowo, ponieważ bazuje
na odpowiednim kodzie tego frameworka (który wykonuje odpowiednie działania w ich
imieniu). Przykładowo, możemy deklaratywnie skonfigurować mechanizm ContextLoarer
Springa w taki sposób, aby automatycznie wczytywał kontekst aplikacji w momencie
uruchamiania aplikacji internetowej. Odpowiednie techniki konfiguracji omówimy w na-
stępnym rozdziale.
Korzystanie komponentów uzyskiwanych z fabryki
Kiedy już fabryka komponentów lub kontekst aplikacji zostaną wczytane, uzyskanie dostępu
do komponentów sprowadza się do wywołania metody getBean() interfejsu BeanFactory:
WeatherService ws = (WeatherService)ctx.getBean("weatherService");
lub jednej z metod któregoś z bardziej zaawansowanych interfejsów:
Map allWeatherServices = ctx.getBeansOfType(WeatherService.class);
%7łądanie od kontenera dostępu do komponentu wywołuje proces jego tworzenia i inicjaliza-
cji, który obejmuje omówioną już fazę wstrzykiwania zależności. Krok wstrzykiwania za-
leżności może z kolei zainicjować proces tworzenia pozostałych komponentów (zależności
pierwszego komponentu) itd., aż do utworzenia kompletnego grafu wzajemnie powiąza-
nych egzemplarzy obiektów.
W związku z opisaną procedurą nasuwa się dość oczywiste pytanie: co należałoby zrobić
z samą fabryką komponentów lub kontekstem aplikacji, aby pozostały kod, który tego wy-
maga, mógł uzyskać do nich dostęp? Obecnie skupiamy się na analizie sposobu konfiguro-
wania i funkcjonowania kontenera, zatem przedstawienie i wyjaśnienie odpowiedzi na to
pytanie odłóżmy na dalszą część tego rozdziału.
98 Spring Framework. Profesjonalne tworzenie oprogramowania w Javie
Pamiętaj, że z wyjątkiem bardzo niewielkiej ilości kodu scalającego zdecydowana więk-
szość kodu aplikacji pisanego i łączonego zgodnie z założeniami IoC nie musi zawierać
żadnych operacji związanych z uzyskiwaniem dostępu do fabryki, ponieważ za zarzą-
dzanie zależnościami pomiędzy obiektami i samymi obiektami odpowiada kontener.
Najprostszą strategią zapewniania odpowiednich proporcji pomiędzy kodem scalają-
cym (niezbędnym do inicjowania pewnych działań) a właściwym kodem aplikacji jest
umieszczenie fabryki komponentów w znanym miejscu, które będzie odpowiadało nie
tylko oczekiwanym zastosowaniom, ale też tym elementom kodu, które będą potrze-
bowały dostępu do tej fabryki. Sam Spring oferuje mechanizm deklaratywnego wczyty-
wania kontekstu dla aplikacji internetowych i składowania tego kontekstu w obiekcie
ServletContext. Co więcej, Spring zawiera klasy pomocnicze przypominające single-
tony, które mogą być z powodzeniem stosowane do składowania i wydobywania z fa-
bryki komponentów (jeśli takie rozwiązanie z jakiegoś powodu wydaje Ci się lepsze lub
jeśli nie istnieje strategia składowania fabryki komponentów w ramach konkretnej
aplikacji).
Konfiguracja komponentów w formacie XML
Mieliśmy już okazję przejrzeć przykładowe pliki z definicjami fabryk komponentów w formacie
XML, jednak do tej pory nie poddaliśmy zawartych tam zapisów szczegółowej analizie.
W największym uproszczeniu definicja fabryki komponentów składa się z elementu beans
(na najwyższym poziomie) oraz jednego lub wielu elementów bean:
"http://www.springframework.org/dtd/spring-beans.dtd"
Prawidłowe elementy i atrybuty pliku definicji szczegółowo opisano w pliku XML DTD
(ang. Document Type Definition) nazwanym spring-beans.dtd. Wspomniany plik DTD
w połączeniu z podręcznikiem użytkownika Springa powinien być traktowany jak ostateczne
zródło informacji o technikach konfiguracji aplikacji. Ogólnie, opcjonalne atrybuty ele-
mentu beans (na najwyższym poziomie elementów XML definicji komponentów) mają
wpływ na zachowanie całego pliku konfiguracji i zawierają domyślne wartości dla rozma-
itych aspektów wszystkich definiowanych komponentów, natomiast większość opcjonalnych
atrybutów i podelementów potomnych elementów bean opisuje konfigurację i cykl życia
poszczególnych komponentów. Plik spring-beans.dtd jest co prawda dołączany do Springa,
jednak z jego zawartością można się zapoznać także w internecie (patrz www.springframe-
work.org/dtd/spring-beans.dtd).
Rozdział 2. Fabryka komponentów i kontekst aplikacji 99
Podstawowa definicja komponentu
Definicja pojedynczego komponentu zawiera wszystkie informacje, których kontener po-
trzebuje do jego utworzenia, w tym trochę szczegółowych danych o cyklu życia kompo-
nentu oraz jego zależnościach. Przyjrzyjmy się dwóm pierwszym składnikom elementu bean.
Identyfikator
W definicji komponentów na najwyższym poziomie hierarchii niemal we wszystkich przy-
padkach definiujemy jeden lub wiele identyfikatorów (lub nazw) komponentów, aby pozo-
stałe komponenty mogły się do nich odwoływać podczas programowego korzystania z da-
nego kontenera. Do definiowania identyfikatorów (lub głównych identyfikatorów)
komponentów służy atrybut ir. Zaletą tego atrybutu jest zgodność z typem XML IDREF
kiedy pozostałe komponenty będą się odwoływały do komponentu za pośrednictwem tak
[ Pobierz całość w formacie PDF ]