[ Pobierz całość w formacie PDF ]
108 Część II Elementy projektów, niewłaściwe techniki oraz przebudowa systemu
W miarę rozbudowywania komercyjnej funkcjonalności aplikacji zachodzi potrzeba odpo-
wiedniego potraktowania problemów związanych z zagadnieniami trwałości, transakcji,
bezpieczeństwa oraz skalowalności usług komercyjnych. Po osiągnięciu pewnego poziomu
złożoności konieczne jest wprowadzenie komponentów sesyjnych i jednostkowych, które
umożliwiają scentralizowane korzystanie z usług komercyjnych przez wszystkich klientów.
Konieczne staje się także wykorzystanie możliwości kontenerów EJB.
Należy pamiętać, że użycie ciężkich komponentów, takich jak komponenty EJB, nie zawsze
znajduje uzasadnienie w wymaganiach stawianych danej aplikacji. Skorzystanie z możliwości
takich komponentów może być jednak konieczne, jeżeli tworzona aplikacja ma spełniać wyso-
kie kryteria bezpieczeństwa, transakcji, elastyczności czy też przetwarzania rozproszonego.
Mechanika
Kod dostępu do danych należy usunąć z obiektów kontrolnych i jednostkowych,
a następnie wyodrębnić go w obiektach dostępu do danych (Data Access Objects,
DAO).
Zobacz Separacja kodu dostępu do danych , rozdział 5.
Rozdzielić kod przetwarzania prezentacji oraz przetwarzania komercyjnego.
Przetwarzanie komercyjne powinno być obsługiwane przez komponenty sesyjne.
Kod przetwarzania prezentacji powinien pozostać w serwletach oraz stronach JSP.
Takie rozwiązanie należy zastosować, jeżeli aplikacja jest na tyle złożona,
że wymaga takiego rozdzielenia oraz jeżeli zachodzi potrzeba skonsolidowania
logiki w warstwie komercyjnej tak, aby wszyscy klienci (a nie tylko klienci
warstwy prezentacji) mogli korzystać z tych samych usług komercyjnych.
Taką funkcjonalność zapewnia wprowadzenie komponentów sesyjnych,
których zadaniem będzie przetwarzanie usług komercyjnych. Komponenty
sesyjne uzyskują dostęp do składu obiektów trwałych poprzez obiekty dostępu
do danych (DAO).
W razie potrzeby dla komponentów sesyjnych można zastosować demarkację,
zarządzaną przez komponenty lub przez pojemniki.
Przejdz do akapitu Fasada sesji , rozdział 8.
Komponenty jednostkowe należy zastosować dla współdzielonych przez model,
transakcyjnych, trwałych obiektów komercyjnych ogólnego zastosowania.
Punkt ten należy pominąć, jeżeli ich użycie nie znajduje odzwierciedlenia
w wymaganiach stawianych aplikacji.
Rozwiązanie to należy zastosować, gdy zwiększa się stopień złożoności
trwałych obiektów komercyjnych i zachodzi potrzeba skorzystania z możliwości
komponentów jednostkowych, takich jak transakcje oraz trwałość zarządzana
przez pojemniki.
Komponenty jednostkowe umożliwiają demarkację transakcji, zarządzaną przez
pojemniki. Pozwala to na deklaratywne programowanie demarkacji transakcji,
bez konieczności kodowania procedur transakcji na stałe w komponentach
jednostkowych.
Przejdz do akapitu Obiekt wartości oraz Jednostka złożona , rozdział 8.
Rozdział 5. Sposoby przebudowy J2EE 109
Warstwę prezentacji należy oddzielić od warstwy komercyjnej za pomocą
delegatów komercyjnych.
Delegacje komercyjne umożliwiają oddzielenie komponentów warstwy
prezentacji od komponentów warstwy komercyjnej i wyodrębnienie z nich
kodu złożonych operacji wyszukiwania i innych szczegółów implementacji.
Przejdz do akapitu Delegat komercyjny , rozdział 8.
Korzystanie z zestawu połączeń
Połączenia z bazą danych nie są współdzielone przez klientów. Przy wywoływaniu bazy
danych klienci sami zarządzają połączeniami.
Wprowadzenie zestawu połączeń pozwala na wstępne zainicjowanie określonej liczby
połączeń, co korzystnie wpływa na elastyczność i wydajność aplikacji.
Rysunek 5.25.
Korzystanie
z zestawu
połączeń
Motywacja
Otwarcie połączenia z bazą danych to dość kosztowna operacja, której przeprowadzenie
wymaga odpowiedniej ilości czasu i zasobów. Ma to wpływ zarówno na wydajność, jak
i na efektywność. Ponieważ w sytuacji, w której każdy klient posługuje się własnym połą-
czeniem, liczba połączeń jest ograniczona, zazwyczaj szybko osiąga ona swą maksymalną
wartość.
Problem ten powstaje w warstwie prezentacji projektów, w których technologia EJB jest
wprowadzana fazami. W takim przypadku komponenty w warstwie prezentacji początkowo
współdziałają bezpośrednio z bazą danych, a następnie kod dostępu do danych zostaje prze-
sunięty do warstwy komercyjnej i wyodrębniony w warstwie EJB. Przejdz do akapitów
Separacja kodu dostępu do danych oraz Przebudowa architektury warstw (rozdział 5.).
110 Część II Elementy projektów, niewłaściwe techniki oraz przebudowa systemu
Mechanika
Należy utworzyć interfejs zarządzania połączeniami, którego metody będą umożliwiały
pobieranie i zwracanie połączeń.
W oparciu o wzorce klasy wydobycia (Extract Class [Fowler]) i (lub) metody
przesunięcia (Move Method [Fowler]) należy przesunąć istniejący kod przydzielania
połączeń do klasy, która implementuje (utworzony w poprzednim punkcie)
interfejs zarządzania połączeniami.
W miejscach, z których usunięto kod połączeń, należy wstawić wywołania
instancji nowej klasy (i jej metod), na przykład:
oraz
.1
Należy pamiętać, że w wersji 2. specyfikacji JDBC opisano standardowy
mechanizm tworzenia zestawu połączeń. Jeżeli mechanizm ten jest dostępny,
to zalecane jest zastosowanie go przy tworzeniu zestawu połączeń. W wersji 2.
specyfikacji JDBC interfejs zarządzania połączeniami nosi nazwę
javaxsql.DataSource i pozwala na przebudowę obiektów połączeń ( ).
Na tym etapie standaryzacja dotyczy jedynie struktury oraz interfejsu.
Nie zmienia się natomiast funkcjonalność.
Implementacja zestawów połączeń jest możliwa po zastosowaniu zalecanej
przebudowy JDBC 2.0 DataSource.
Aby zaimplementować zestawy połączeń, należy odpowiednio dostosować
implementację metod zwracających połączenia (znajdujących się w klasie
zarządzającej połączeniami), inicjując w ten sposób wstępnie pewną liczbę
obiektów połączeń ( ), a następnie rozdzielić je między klientów.
Istnieje wiele powszechnie dostępnych implementacji, które można wykorzystać
w tym celu.
Klientami utworzonych w ten sposób instancji klasy zarządzającej połączeniami
[ Pobierz całość w formacie PDF ]