[ Pobierz całość w formacie PDF ]

stanowią uniwersalny zarys tego, do czego należy dążyć w naszych środowiskach pro-
jektowych.
Struktura projektu komplikuje się wraz ze wzrostem rozmiarów wytwarzanej aplikacji.
Tylko zachowując maksymalną prostotę stosowanych struktur od samego początku
możemy choć w części uniknąć niepotrzebnej złożoności podczas dalszego rozwoju
projektu.
We wszystkich projektach platformy J2EE struktura katalogów jest dzielona na cztery
osobne obszary: plików z
ródłowych, plików skompilowanych, bibliotek i plików goto-
wych do wdrożenia. Każdy z tych obszarów jest reprezentowany w systemie plików
przez własny katalog, a cztery katalogi wymienionych obszarów znajdują się na szczycie
hierarchii katalogowej projektu.
Na rysunku 12.3 przedstawiono strukturę katalogów na najwyższym poziomie hierarchii
katalogowej projektu.
Rysunek 12.3.
Struktura katalogów
na najwyższym
poziomie projektu
Naszą analizę rozpoczniemy od szczegółowego omówienia katalogu z
ródłowego (source).
Katalog z
ródłowy (source)
Katalog z
ródłowy zawiera wszystkie artefakty programowe, które są wykorzystywane
w procesie konstruowania aplikacji. Nie chodzi tu wyłącznie o pliki z
ródłowe Javy 
mogą to być takie artefakty jak skrypty kompilacji, pliki właściwości, deskryptory wdro-
żenia, skrypty baz danych czy schematy XML. Organizację katalogu z
ródłowego przed-
stawiono na rysunku 12.4.
Taka struktura projektu ma ścisły związek z wymaganiami w zakresie tworzenia poje-
dynczego pliku EAR, gdzie każdy gotowy do wdrożenia moduł jest utrzymywany w for-
mie podprojektu.
342 Część IV f& Z
rodowiska dynamiczne
Rysunek 12.4.
Struktura katalogu
z
ródłowego
Cały kod z
ródłowy powinien się znajdować w odpowiednich pakietach w strukturze
katalogowej. Warto też rozważyć dodanie równoległego katalogu z
ródłowego dla
każdego z komponentów, co może bardzo ułatwić zarządzanie kodem dla testów
jednostkowych.
Analiza struktury katalogowej przedstawionej na rysunku 12.4 pozwala zidentyfikować
następujące moduły:
Katalog META-INF zawiera wszystkie pliki potrzebne do zbudowania
gotowego do wdrożenia pliku EAR.
Moduły EJB zostały umieszczone w osobnym katalogu. Plik EAR może
obejmować wiele modułów. Ze struktury przedstawionej na rysunku 12.4
wynika, że plik EAR będzie zawierał pojedynczy moduł (komponent) EJB:
MyEJB.
Wspólne biblioteki, które są kompilowane jako część projektu, powinny być
składowane w ramach struktury katalogowej (patrz biblioteka MyLib
na rysunku 12.4).
Struktura katalogowa aplikacji internetowych jest najbardziej skomplikowana,
ponieważ na każdą z tych aplikacji składa się wiele typów plików.
W analizowanym przykładzie można wyróżnić aplikację internetową MyWebApp,
która dobrze demonstruje układ i organizację poszczególnych typów plików.
Rozdział 12. f& Optymalne kompilowanie systemów 343
Dla każdego modułu składającego się na wersję systemu gotową do wdrożenia na
serwerze aplikacji J2EE należy zdefiniować osobny plik build.xml. Pliki kompilacji są
autonomicznymi strukturami, za pomocą których można kompilować poszczególne mo-
duły niezależnie od siebie. Pliki kompilacji zawierają oczywiście zapisy reprezentujące
relacje łączące różne moduły systemu. Aplikacja internetowa najprawdopodobniej będzie
się odwoływała do warstwy biznesowej, co oznacza, że będzie istniała zależność łą-
cząca tę aplikację z modułem EJB. Wszystkie tego rodzaju związki powinny być za-
rządzane właśnie przez pliki kompilacji.
Wszystkie pliki kompilacji (dotyczące różnych modułów) powinny być spójne przy-
najmniej w obszarze nazewnictwa zadań. Każdy z tych plików musi wykorzystywać
możliwie podobny zbiór zadań kompilacji. Na szczycie hierarchii (w głównym kata-
logu z
ródłowym) istnieje plik kompilacji, który odpowiada za sterowanie całym pro-
cesem. Jest to typowy przykład pliku Anta, który deleguje odpowiednie zadania do
plików kompilacji poszczególnych podprojektów.
Wywołania zadań użyte w pliku kompilacji projektu są kolejno przekazywane w dół
hierarchii do właściwych zadań poszczególnych podprojektów. Chociaż każdy plik
kompilacji zawiera ten sam zbiór zadań, podejmowane działania są uzależnione od typów
modułów, za których kompilowanie odpowiadają. Przykładowo, w przypadku modułu
aplikacji internetowej zadanie package generuje plik WAR, natomiast w przypadku
pliku kompilacji projektu na najwyższym poziomie hierarchii to samo zadanie generuje
plik EAR.
Bardzo istotna jest kolejność kompilowania podprojektów  proces powinien się rozpo-
czynać od modułów na najniższym poziomie hierarchii i kończyć na jej szczycie (np.
wygenerowaniem zbiorczego pliku EAR). Właśnie podejście  od dołu i bezwzględne
wymuszanie przestrzegania zależności prowadzi do osiągnięcia procesu kompilacji na
poziomie gwarantującym łatwość konserwacji i logiczną spójność budowanego systemu.
Katalog bibliotek (lib)
Katalog bibliotek zawiera wszystkie zewnętrzne biblioteki. Skrypty kompilacji często
odwołują się do tego katalogu podczas kompilowania modułów systemu. Podczas groma-
dzenia zasobów składających się na gotowy do wdrożenia plik EAR wszystkie biblio-
teki, których obecność w czasie wykonywania programu jest niezbędna, są kopiowane
z katalogu lib.
Katalog plików skompilowanych (build)
Wszystkie dane wyjściowe procesu kompilacji plików z katalogu z
ródłowego (source)
trafiają do katalogu plików skompilowanych (build). Utrzymywanie plików z
ródło-
wych z dala od skompilowanych plików binarnych pozwala zachować należyty porzą-
dek w strukturze katalogowej projektu. Taki podział na dwa różne katalogi oznacza,
że katalog plików skompilowanych może np. zostać w dowolnym momencie usunięty [ Pobierz całość w formacie PDF ]