J 2 EE tervezsi mintk Miskolci Egyetem Alkalmazott

J 2 EE tervezési minták Miskolci Egyetem Alkalmazott Informatikai Tanszék 2005 1

J 2 EE tervezési minták

MVC modell • Model / View / Controller (MVC) egy architekturális tervezési minta. A Modell adatot, a View megjelenítést, a Controller vezérlést (a modell és view vezérlését) jelenti. MVC megkísérli a modell, adat és a megjelenítés szétválasztását elkülönített kezelését. • Eredetileg a Smalltalk nyelvből származik. • Előnyök: – Egyszerű és rugalmas alkalmazás architektúra tervezés – Komplex objektumok egyszerűsítése – Az objektumok újrahasznosításának elősegítése

• A modell belső reprezentációja az adatoknak, a view éltalában egy GUI komponens, a controller koordinálja a modell és a view viselkedését. • Példa (nem J 2 EE): A felhasználó egy felhasználói interfészen (GUIn) keresztül manipulálja egy DB szerveren tárolt adatokat. – MVC megoldás: Nem építjük be az üzleti logikát a megjelenítésért felelős JSP vagy Swing-es osztályokba (ahogy első látásra egyszerűnek látszik), hanem tervezünk egy adat-manipulátor osztályt (Data. Manager). Ez a manipulátor a következő általános funkciókat valósítja meg: adatbetöltés, keresés, módosítás. A manipulátor osztály olyan műveletekkel rendelkezik, amelyek függetlenek az adatok megjelenítésétől. A megjelenítésért felelős osztályok nem közvetlenül az adatokat, hanem a Data. Managert érik (érhetik) el. – Ebben a megoldásban a DB szerver, mint Modell, a Data. Manager, mint Controller, a GUI, mint View szerepel. – Előnyök: • A Data. Managernek lehet könnyen konfigurálható lokális és távoli módja is egyszerre. • A View könnyen cserélhető (mobil telefon, Swing, html), mivel nem közvetlenül kapcsolódik a adatokhoz. • A DB szerver cseréje jól behatárolt változásokat jelent a Data. Managerben.

Wireless customer Administrator B 2 B Agent Web customer HTML view WML view Applet view Enterprise Information System Webes bolt XML view / Web service

állapotváltozás Model - magában foglalja az Controller alkalmazás állapotát - válaszol az állapotkérésekre - értesít az állapotváltozásokról - meghatározza az alkalmazás viselkedését - felhasználó akcióit, modell manipulációra alakítja - view-okat választ a kérésektől függően változás értesítés állapot lekérdezés nézet kiválasztás View -a modell megjelenítése - feldolgozza a modell változásait - a vezérlőnek továbbítja a felhasználó parancsait - nézetváltást tesz lehetővé felhasználói beavatkozás esemény függvényhívás MVC modell J 2 EE környezetben

Modell – a modell reprezentálja az adatokat és az üzleti szabályokat. Az adatok közvetlen eléréséhez, megváltoztatásához kizárólagos joga van. View – a nézet jeleníti meg a modell tartalmát. Csak a modellen keresztül érheti el az adatokat, a megjelenítésért pedig kizárólagosan felelős. A modell változása esetén felelős a változások következetes megjelenítéséért. Push model: a view regisztrálja magát a modellben a változások nyomon követése érdekében. Pull model: a modell megváltozásakor a view felelős azért, hogy mindig az aktuális, legfrissebb adatok jelenjenek meg. Controller: a vezérlő felelős a felhasználói interakciók fordításáért. A vezérlő az interakciókat modell manipulációkra fordítja. Egyszerű egyedülálló GUI kliens esetén az interakciók egér események, de összetettebb Web alkalmazások esetén már HTTP GET és POST kérések. A felhasználói interakciók alapján a vezérlő nézetet vált, modell állapotváltozást eszközöl (azaz üzleti folyamatokat indít). J 2 EE megvalósítás. Java. Server Pages (JSP) oldalakat nézeteknek, a Servletek vezérlőkként és az Enterprise Java. Beans (EJB) komponenseket modellnek tekinthetjük.

• Előnyök: – A modell komponensek újrahasznosítása: A modell és nézet szétválasztása könnyen lehetővé teszi a modell újrahasznosítását különböző környezetekben. – Tesztelés: A tesztelés folyamata egyszerűbb, mivel a vezérlő és a modell függetlenül tesztelhető. – Könnyű kiegészíthetőség: Új megjelenítéssel bővíteni a rendszert annyit tesz, mint egy új nézet fejlesztése és a vezérlő esetleges kibővítése. – A rendszer komplexitása természetesen növekszik a hozzáadott osztályok számának növelésével, mégis a változás menedzsment számára könnyebbé (olcsóbbá) válik a karbantartás.

Front controller • Olyan központi vezérlő, amelyen minden kliens kérés átmegy. – üzenet feldolgozás központosítása Front controller – üzleti logikája eldönti a kérések feldolgozási módját

Data Access Object (DAO) • Adatelérő objektum. Perzisztens (állandó) adatok eléréséhez • J 2 EE alkalmazásoknak szükségük van perzisztens adatok elérésére. Érdemes API-t készíteni, amelyen keresztül elérhetőek az adatok, de a konkrét adatelérés implementációját eltakarják a használó objektumok elől. • A DAO implementálja az elérési mechanizmust a különböző adatforráshoz: – RDBMS, XML B 2 B service, LDAP, CORBA IIOP, Socket

Business Object: A kliens szerepét játssza. Lehet session bean, entity bean, servlet vagy tetszőleges Java objektum. DAO: Elfedi az alatta lévő adatelérés implementációját. Data. Source: Ez az objektum az adatforrás implementációja. Transfer object: ez a valóságos adathordozó objektum.

// DAO Factory létrehozása DAOFactory cloudscape. Factory = DAOFactory. get. DAOFactory(DAOFactory. DAOCL OUDSCAPE); // DAO objektum létrehozása Customer. DAO cust. DAO = cloudscape. Factory. get. Customer. DAO(); // új vevő létrehozása int new. Cust. No = cust. DAO. insert. Customer(. . . ); // vevő keresése Customer cust = cust. DAO. find. Customer(. . . ); // vevő adatainak módosítása (Transfer Object) cust. set. Address(. . . ); cust. set. Email(. . . ); // módosítás cust. DAO. update. Customer(cust); public interface Customer. DAO { public int insert. Customer(. . . ); public boolean delete. Customer(. . . ); public Customer find. Customer(. . . ); public boolean update. Customer(. . . ); public Row. Set select. Customers. RS(. . . ); public Collection select. Customers. TO(. . . ); } // törlés cust. DAO. delete. Customer(. . . ); // keresés egy adott kritérium szerint criteria=new Customer(); criteria. set. City("New York"); Collection customers. List = cust. DAO. select. Customers. TO(criteria);

Transfer Object • Adathordozó osztály, amely távoli üzleti metódusok visszatérési típusként működik. Value Object-nek is szokták nevezni. • Előnyei: – Hálózati forgalom csökkentése. (egy osztály tartalmaz képeket és egész, lebegőpontos attribútumokat egyaránt. Olyan metódusok amelyek csak a számokat változtatják, azoknak nem kell elküldeni a képeket a hálózaton keresztül. )

A kliens a Business. Objekt-en keresztül adatot kér a szervertől. A szerveren lévő Business. Object létrehoz egy Value. Object-et a szükséges adatokkal és visszaküldi a kliens oldalra. Az átadás érték szerinti, tehát olyan mintha a kilens oldalon létrejönne egy másolat az eredeti Value. Object-ről, tehát minden accessor (set/get) hívás lokális hívássá válik értelemszerűen. A tranzakció végén az eredmény Value. Object visszakerül a szerver oldalra és megtörténnek a tényleges adat módosítások.

Intercepting Filter • Szolgáltatások biztosítása a kliensek számára a a kliens és szerver kód módosítása nélkül. • Alkalmazási területek – Logging, Authentikáció, Tranzakció kezelés – Debugging – Kérések elő és utófeldolgozása (compressing)

Szűrők láncolata – osztály diagram Szűrők láncolata – szekvencia diagram

Egyszerű példa: My. Filter osztály minden bejövő HTTP kérést a filterláncnak továbbít. public class My. Filter implements Filter { public void do. Filter(Servlet. Request request, Servlet. Response resonse, Filter. Chain chain) throws Servlet. Exception, IOException { //work on request and response chain. do. Filter(request, response); } public void init(…)…. } <web-app> <filter-name>My. Filter</filter-name> <display-name>My. Cool. Filter</display-name> <description>my filter</description> <filter-class>package. My. Filter</filter-class> <init-param> <param-name>yyy</param-name> <param-value>/xxx/zzz</param-value> </init-param> </filter> <filter-mapping> <filter-name>My. Filter</filter-name> <url-pattern>/xxx. jsp</url-pattern> </filter-mapping> </web-app> Szerver oldalon a web. xml szövegesen tartalmazza a filter leírását és mappelését egy adott URL-hez.

Business delegate • Köztes osztály, amely elválasztja kliens réteget a középső (üzleti) rétegtől. • A többrétegű alkalmazások távoli metódus hívásokkal érik el a távoli objektumokat. Ezt a folyamatot fedi el a Business delegátor módszer. • Kliens oldali cache alkalmazása. Business delegate – osztály diagram

A kliens a Business. Delegate objektumot használja minden távoli objektum lekérése előtt. A Business. Delegate a Lookup. Service segítségével megkeresi a szolgáltatás helyét. (gondoljunk osztott szolgáltatásokra. ) A későbbi keresések (lookup) elkerülése végett ID-ket is használhatunk. Ami egy távoli kezelő objektum (handler) string reprezentációja. A legközelebbi híváskor a handler könnyen ujra létrehozza a kapcsolatot a távoli Business. Service objektummal.

A kliens a Business. Delegate objektumot hívja meg, az előzőleg létrehozott ID segítségével. A Service. Locator a string ID-t átalakítja a megfelelő Handler objektumra, amely újra kapcsolatot létesít a távoli Business. Service objektummal. A Business. Service elérése ezzel a módszerrel felgyorsul.