J2EE tervezési minták Miskolci Egyetem Alkalmazott Informatikai Tanszék

Az előadások a következő témára: "J2EE tervezési minták Miskolci Egyetem Alkalmazott Informatikai Tanszék"— Előadás másolata:

1 J2EE tervezési minták Miskolci Egyetem Alkalmazott Informatikai Tanszék 2005 1

2 J2EE tervezési minták

3 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

4 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 J2EE): A felhasználó egy felhasználói interfészen (GUI- n) 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 (DataManager). 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 DataManagert érik (érhetik) el. –Ebben a megoldásban a DB szerver, mint Modell, a DataManager, mint Controller, a GUI, mint View szerepel. –Előnyök: A DataManagernek 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 DataManagerben.

5 Wireless customer Administrator B2B Agent Web customer Enterprise Information System HTML view WML viewApplet view XML view / Web service Webes bolt

6 állapot lekérdezés nézet kiválasztás Model - magában foglalja az alkalmazás állapotát - válaszol az állapotkérésekre - értesít az állapotváltozásokról 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é Controller - 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 állapotváltozás felhasználói beavatkozás változás értesítés esemény függvényhívás MVC modell J2EE környezetben

7 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). J2EE megvalósítás. JavaServer Pages (JSP) oldalakat nézeteknek, a Servletek vezérlőkként és az Enterprise JavaBeans (EJB) komponenseket modellnek tekinthetjük.

8 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.

9 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

10 Data Access Object (DAO) Adatelérő objektum. Perzisztens (állandó) adatok eléréséhez J2EE 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 B2B service, LDAP, CORBA IIOP, Socket

11 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. DataSource: Ez az objektum az adatforrás implementációja. Transfer object: ez a valóságos adathordozó objektum.

12 // DAO Factory létrehozása DAOFactory cloudscapeFactory = DAOFactory.getDAOFactory(DAOFactory.DAOCL OUDSCAPE); // DAO objektum létrehozása CustomerDAO custDAO = cloudscapeFactory.getCustomerDAO(); // új vevő létrehozása int newCustNo = custDAO.insertCustomer(...); // vevő keresése Customer cust = custDAO.findCustomer(...); // vevő adatainak módosítása (Transfer Object) cust.setAddress(...); cust.setEmail(...); // módosítás custDAO.updateCustomer(cust); // törlés custDAO.deleteCustomer(...); // keresés egy adott kritérium szerint criteria=new Customer(); criteria.setCity("New York"); Collection customersList = custDAO.selectCustomersTO(criteria); public interface CustomerDAO { public int insertCustomer(...); public boolean deleteCustomer(...); public Customer findCustomer(...); public boolean updateCustomer(...); public RowSet selectCustomersRS(...); public Collection selectCustomersTO(...); }

13 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.)

14 A kliens a BusinessObjekt-en keresztül adatot kér a szervertől. A szerveren lévő BusinessObject létrehoz egy ValueObject-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 ValueObject-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 ValueObject visszakerül a szerver oldalra és megtörténnek a tényleges adat módosítások.

15 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)

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

17 public class MyFilter implements Filter { public void doFilter(ServletRequest request, ServletResponse resonse, FilterChain chain) throws ServletException, IOException { //work on request and response chain.doFilter(request, response); } public void init(…)…. } MyFilter MyCoolFilter my filter package.MyFilter yyy /xxx/zzz MyFilter /xxx.jsp Egyszerű példa: MyFilter osztály minden bejövő HTTP kérést a filterláncnak továbbít. Szerver oldalon a web.xml szövegesen tartalmazza a filter leírását és mappelését egy adott URL-hez.

18 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

19 A kliens a BusinessDelegate objektumot használja minden távoli objektum lekérése előtt. A BusinessDelegate a LookupService 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 BusinessService objektummal.

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