Ebben a cikksorozatban megpróbálom bemutatni, hogy hogyan is épül fel egy JavaEE alkalmazás szerintem, hogy milyen részekből áll, milyen tervezési mintákat érdemes használni, melyik mire való. (Remélem azért majd valaki hasznosnak találja, ha nem, legalább később vissza tudom nézni, hogy miért is így csináltam. :-) ) Első körben a szerverrel akarok foglalkozni, hiszen ott található az alkalmazás lelke, az üzleti logika, a kliensből csak azzal a résszel foglalkozok, ami a szerverhez kötődik.
Egy ilyen alkalmazás 3 részből áll ugyebár – ezért is hívják 3 rétegű alkalmazásnak :-) -, a GUI(Graphical User Interface – Felhasználói felület), a BLL(Business Logic Layer – Üzleti logika) és a DAL (Data Access Layer – Adatelérési réteg). JavaEE-ben ez úgy néz ki, hogy a program „irányító” része a GUI, ami egy ablakos alkalmazás a kliens gépen. Ez rendez minden felhasználói interakciót, tartja nyilván a program állapotát, hogy a felhasználó hol tart és mit is csinál éppen. A többi rész az alkalmazásszerveren található, ezek az alkalmazásszerver által kezelt lazán csatolt objektumok halmaza. Amikor a felhasználó olyan műveletet végez, amihez szükséges bármilyen üzleti folyamat indítására, akkor a kliens meghívja az egyik objektum egyik függvényét, aminek feladata a kliens által adott információk feldolgozása, és ha szükséges új információk előállítása és átadása a kliensnek.
Ebből kiindulva az alkalmazás architektúrája – mármint a szerver oldal és a szerver oldalhoz szervesen kapcsolódó kliens részek - a következőképpen néz ki (Kinagyítva jobb):
Az ábra értelmezését mindjárt leírom, de előtte egy kis megjegyzés:
Van egy nagyon jó leírás, amit a Sun adott ki a J2EE fejlesztés során használható/ajánlott tervezési mintákról. Ezt szerintem érdemes mindenkinek megnézni és értelmezni. Mivel még J2EE-hez készült, ezért a példaprogram részek nem használhatóak, de a minták leírása részletes és jól összefoglalja a problémát, amire megoldást nyújtanak és a működési elvüket.
És most összefoglalnám néhány szóban, hogy az ábrán szereplő „krumplik” mit is takarnának. Mindegyik egy objektum és a mindegyik egy tervezési mintát valósít meg. Lássunk akkor egy rövid összefoglalót róluk:
Entity
Ezt remélhetőleg nem kell bemutatni, ez az alapja a JavaEE perzisztenciának. Szokták még ha jól emlékszem EJB3-as Entity Bean-nek is hívni – hibásan, hiszen ennek már nincs köze a régi Entity Bean-ekhez. Gyakorlatilag az adatbázis adatok leképezése objektumokba.
DTO
Data Transfer Object vagy Value Object. A lényege az, hogy az üzletileg egybe tartozó adatokat fogja össze egyetlen egységbe, hogy az adatokat könnyen, egy egységként lehessen utaztatni a rétegek között. A JavaEE specifikáció szerint az Entity is alkalmas DTO-nak, hogy ezzel én miért nem értek egyet, arról majd később, egy külön cikkben fogok kitérni.
Az ábra alján próbáltam szemléltetni az alsó nyilakkal, hogy a két adatszállító objektum típust melyik rétegek ismerik, melyek között mozognak. Hogy miért így, arról is majd később beszélek.
DAO
Osztályok, amelyeknek feladata az Entity-k kezelése. A lényege, hogy elrejti a feljebb található rétegek elől az adatbázis felépítését, hiszen azok a DAO egy-egy funkcióját hívják meg, így lépve kapcsolatba az adatbázissal, arról nincs információjuk, hogy a nekik szükséges információ honnan, milyen módon kerül hozzájuk. Ha a program rétegei nem mosódnak egybe, akkor az entity-ket kezelő EntityManager osztály csak itt a DAO-ban szabad, hogy megjelenjen.
BL
Önkényesen neveztem el így, mert jobb nevet nem találtam. Ez az osztály egy Session Bean, amely az üzleti folyamatokat valósítja meg. Minden függvénye egy üzleti funkciónak felel meg, a kliens ezeket a függvényeket hívja. (Hívná, ha nem használnánk még egy réteget, hogy miért, arról később.)
Mapper
A fent említett Sun-os leírásban ez Transfer Object Assembler néven szerepel, feladata a DTO-k és az entity-k közti konverzió végrehajtása, illetve én még egy szerepet szánok neki, a DTO-ban érkező adatok validálása.
Facade
A Facade osztály a facade – homlokzat - tervezési minta megvalósítása. Feladata, hogy egy egységes felületet biztosítson a rendszerben található szolgáltatások elérésére. Ennek a nagy előnye az, hogy a kliens bármilyen szolgáltatást is kíván igénybe venni azt egységesen tudja megtenni, ráadásul mivel a szolgáltatásoknak létezik egy közös belépési pontja, így az olyan feladatokat, amiket minden funkciónál végre jókell hajtani– mint például az authentikáció ellenőrzése vagy a kivételek átalakítása – itt el lehet intézni.
Business Delegate
Ez a kakukktojás, hiszen ez az objektum a kliensen található. Azért tartozik mégis ehhez a felsoroláshoz, mert ennek a feladata a kliens többi része elől elrejteni azt, hogy a program többi része egy szerveren található. Ő kezeli a kapcsolatokat a szerverrel, az authentikációs információkat, kezeli a szerverről érkező kivételeket.
Megpróbáltam összefoglalni, hogy kb. milyen részei, rétegei vannak egy JavaEE programnak a szerver oldalon és bemutatni őket pár szóban. A folytatásban – ha minden jól megy – részletesebben is bemutatom őket.
