Szakdolgozat. Kovács Lilla

Átírás

1 Szakdolgozat Kovács Lilla Debrecen 2009

2 Debreceni Egyetem Informatikai Kar Szoftverfejlesztés Java környezetben Témavezetı: Espák Miklós Egyetemi tanársegéd Készítette: Kovács Lilla Programtervezı informatikus BSc Debrecen 2009

3 Tartalomjegyzék Tartalomjegyzék Bevezetés Témaválasztás indoklása A perzisztencia fogalma Relációs adatbázisok ORM (Object Relational Mapping) Java Data Objects (JDO) JDO vagy JDBC? JDO osztályok Perzisztencia keretrendszerek Entity Enterprise Java Beans (EJBs) Java Naming and Directory Interface (JNDI) TopLink Java Persistence API Entitások Entitások identitása Metaadatok Osztályra vonatkozó metaadatok Mezı és property metaadatok Entitások relációja Persistence Unit Persistence Context Lekérdezések (Query) Java Persistence Query Language (JPQL) Leszármaztatás Hibernate A Hibernate felépítése Konfiguráció Hibernate Query Language (HQL) Hibernate Annotations Query-k A programról Összefoglalás Függelék Köszönetnyilvánítás Irodalomjegyzék

4 1. Bevezetés A szoftverfejlesztés az informatikának azon területe, mely az utóbbi tíz évben rohamos fejlıdésnek indult. Új módszerek, eszközök, irányzatok jelentek meg, ilyen például a komponens-technológia - melyben az újrafelhasználható komponensek speciális funkciókat írnak le, vagy hajtanak végre -, az aspektusorientált technológia, az egymással folyamatosan versengı Java és.net technológiák, az agilis módszertanok. A Java nyelv a hozzá kapcsolódó technológiákkal folyamatosan fejlıdik. Az évek során kifejlesztettek néhány keretrendszert, melyek segítik az objektum-relációs leképezések és a perzisztencia kezelését. A dolgozatomban néhány keretrendszert, technológiát szeretnék bemutatni, többek között a Hibernate, Java Persistence API, EJBs, Object Relational Mapping, Java Data Object, TopLink használatát (elemek, kapcsolatok, lehetıségek stb.) 1.1. Témaválasztás indoklása Szakdolgozatom elsıdleges célja a tapasztalatszerzés és a tanulás volt. Tanulmányaim alatt inkább a Java alapjainak elsajátítása volt a cél, ezért döntöttem amellett, hogy egy számomra új dologgal ismerkedjek meg közelebbrıl. Bizonyos elıismerettel rendelkezem a JSP terén, így a dolgozat mellett egy Java alapú webes alkalmazást készítettem, mely a Hibernate alapjainak elsajátításában nyújtott segítséget. A dolgozatban igyekszem példákon keresztül szemléltetni a technológiák, keretrendszerek elemeinek mőködését, a könnyebb megértés érdekében. 2

5 2. A perzisztencia fogalma A perzisztencia tulajdonképpen az objektumhierarchia egy részének adatbázisban való tárolását, illetve onnan visszatöltését jelenti. Megvalósítása meglehetısen munkaigényes. Ahhoz, hogy tudjuk, hogy melyik objektum változott meg, figyelemmel kell kísérni az objektumok mezıit. Szinte minden alkalmazásfejlesztés alapjául szolgál. A perzisztens adat egy olyan információ, mely képes túlélni az ıt létrehozó programot. A bonyolultabb programok nagy része használ perzisztens adatokat. Könnyősúlyú perzisztencia (lightweight persistence): perzisztens adatok tárolását, az adattárból való visszanyerést szolgálja, ezzel megkönnyítve a programozó munkáját. A szerializáció is egyfajta könnyősúlyú perzisztencia, ahol a Java objektumok fájlba történı perzisztálása könnyedén megoldható Relációs adatbázisok A relációs adatbázisok régóta mőködı, robosztus rendszerek, hatékonyan kezelik a perzisztens adatokat. Az adatok nagyon hosszú életőek, sokkal tovább maradnak életben, mint más alkalmazások. A relációs adatbázis kezelı rendszerek SQL-alapúak, ezért gyakran nevezzük ıket SQL adatbázis kezelı rendszereknek. Az eszköz, mely a programozót segíti az adatbázisok által nyújtott szolgáltatások használatát, az adatbázis perzisztencia eszköz, más néven JDBC. Gyors elérést tesz lehetıvé. A Java nyelv JDBC API-n keresztül támogatja az adatbázis-kezelést. A JDBC-t használó programokban módosításokat az SQL-nyelv eszközeivel hajthatunk végre (SELECT, INSERT stb.). Az adatbázishoz való kapcsolódás a Java nyelvbıl könnyedén megoldható, de a programozó feladata az, hogy a JDBC adatait objektumokká alakítsa át, viszont ez néhány problémához vezethet, például, ha egy mezı neve megváltozik, akkor az ahhoz tartozó attribútumot a Java kódban is meg kell változtatni. A célunk olyan kódot készíteni, mely elmenti és kinyeri az objektumokat az adatbázisba/adatbázisból. Tehát azt mondhatjuk, hogy a relációs adatbázis és az SQL a perzisztencia kezelésére a legjobb megoldás. 3

6 2.2. ORM (Object Relational Mapping) Az ORM az objektumok relációs adatbázisban való tárolása szolgál, mely metaadatokat használ az objektumok és az adatbázis közötti kapcsolat leírására egyfajta adatkonverzió az objektumorientált nyelv és a relációs adatbázis között. Metaadat: adat az adatról, azaz az adat használatára vonatkozó összes információ, tény együttese. Az ilyen rendszerektıl mit várunk el? egy API-t az objektumok CRUD mőveleteire (create / read / update / delete) lekérdezı nyelv / API az osztályokra és azok adattagjaira vonatkozóan egy keretrendszer a leképezések definiálására laza kapcsolatok felderítése, piszkos adatok ellenırzése, egyéb optimalizáló funkció megvalósítása Elınye, hogy legtöbbször csökkenti a programkód sorainak számát, ezért a rendszer sokkal hibatőrıbb, robosztusabb lesz mivel kevesebb a sorok száma, a hibázási lehetıség is kisebb. Az ORM fajtái: Pure relational (Tiszta reláció): az egész alkalmazás a relációs modell és az SQL mőveletek szerint készül el. Kis alkalmazásoknál kiváló megoldás. Hátránya: nem hordozható, és nehezen karbantartható. Light object mapping (Könnyősúlyú objektum leképezés): a tervezési minták elrejtik az SQL kódot. Az osztályok leképezése az adatbázisba manuálisan történik. Ideális kevés számú entitás esetén, vagy olyan alkalmazásoknál, melyek generikus nyelvi eszközökkel dolgoznak. Medium object mapping (Középsúlyú objektum leképezés): az objektum-modell köré tervezték. Az SQL kód elıállítása fordítási vagy futási idıben történik. A lekérdezést el lehet végezni valamilyen OO nyelven. Általában közepes mérető alkalmazásoknál használják, és fontos a hordozhatóság. Full object mapping (Teljes objektum leképezés): bonyolult objektummodellezés, beleértve a kompozíciót egész-rész viszony, ahol a rész élettartama az egésztıl függ, vagyis a rész soha nem élheti túl az egészet -, a polimorfizmust alosztályban egy 4

7 átvett metódus implementációja megváltozik, de a specifikáció nem-, az öröklıdést és a perzisztenciát. Egy perzisztens osztály nem öröklıdik, és nem implementál semmilyen interfészt. 5

8 3. Java Data Objects (JDO) A Java Data Objects strukturált Java objektumok adatbázisban való tárolását szolgálja. A JDO specifikáció egy magas szintő API-t használ az objektumperzisztencia és a relációs adatbázis-kezelés megvalósítására. Tartalmaz: közvetlen, egyszerő I/O fájlkezelést JDBC-t: az összes funkcionalitásával. Itt a fejlesztı dolga a mezıkben lévı adatok tárolása, kezelése, ezért neki ismernie kell valamilyen lekérdezı nyelvet (Például SQL-t). Enterprise Java Beaneket Bean-Managed Persistence entity beaneket (BMP): EJB rendszerben az entity beanek tartalmának hosszútávú tárolását a beanek maguk végzik. A beanek függetlenségre törekednek, és nincsenek közvetlen kapcsolatban más BMP beanekkel. BMP használata megköveteli az entitások létrehozására, törlésére, tárolására, keresésére vonatkozó metódusok megírását. Container-Managed Persistence entity beaneket (CMP): a beanek tartalmának hosszútávú rögzítését az ıket befogadó konténer végzi. A CMP megengedi több beannek, hogy valamiféle kapcsolat legyen közöttük. Két modellel rendelkezik: lokális és távoli, ennek megfelelıen lokális és távoli interfészeket használnak. Egy CMP modell közelebb áll egy Java modellhez, legfıképpen az enterprise beanek közötti paraméterátadásokra vonatkozóan. Java Persistence API-t A BMP jobb teljesítményt, nagyobb flexibilitást elérés bármilyen adatforrásból, például adatbázis, szövegfájlok stb. - és alkalmazásszerver függetlenséget nyújt, a CMP viszont könnyebb karbantarthatóságot és kényelmet biztosít. A JDO elınyei: Kényelmes használat: a programozónak csak a domain modellre kell figyelnie, a perzisztencia-kezelés a JDO feladata. Hordozhatóság 6

9 Adatbázis-függetlenség: különféle adattárolási módot megenged, beleértve a relációs adatbázist, XML vagy más, egyszerő szöveges fájlokat. Nagy teljesítmény: a JDO implementáció optimalizálja az adatelérést, így érhetı el jobb teljesítmény. EJB kiegészítés: az EJB sajátosságai közül néhányat használ, ilyen például a távoli metódushívás, tranzakció-kezelés, biztonság - ugyanazt a domain modellt használva az egész alkalmazásra JDO vagy JDBC? Igazából a JDO nem arra törekszik, hogy a JDBC helyébe lépjen. Elképzelhetjük úgy is, mintha a JDO egy réteg lenne a JBDC felett. Mindkettınek megvannak az elınyei és a hátrányai. A JDO elrejti a fejlesztı elıl az sql utasításokat, így ez kényelmesebbé teszi a programozást, nincs szükség a nyelv mélyebb ismeretére. Ha nem szeretnénk lekérdezéseket írni, a lekérdezés eredményeképpen kapott eredményhalmazokat Java objektumokká alakítani, akkor a JDO a legjobb választás. Viszont a JDBC a programozónak rugalmasságot biztosít, azáltal, hogy közvetlen hozzáférési/vezérlési lehetısége van az adatbázishoz, éppen ezért gyorsabb a mőködése, mint a JDO-nak. A JDO lekérdezı nyelve a JDOQL. A JDOQL inkább Java, mint SQL alapokon áll. Mőködése a következıképpen történik: a JDO kap egy sztringet JDOQL formában, és ezt a megfelelı SQL utasítássá konvertálja, majd ezen SQL utasítás által manipulálható(ak) az adatbázis megfelelı eleme(i) JDO osztályok Háromféle osztályt különböztetünk meg: Persistence-capable (perzisztenciára alkalmas): azon osztályok, melynek a példányait perzisztens módon tudjuk elmenteni valamilyen adattárolóba. 7

10 Persistence-aware (perzisztencia-tudatos): ezek az osztályok mapipulálják a persistencecapable osztályokat. A JDOHelper osztály szolgáltat olyan metódusokat, melyek egy persistence-capable osztály példányainak a perzisztens állapotát lekérdezi. Normal (normál): nem perzisztens osztályok, sıt nincs is semmiféle fogalmuk a perzisztenciáról JDO példányok életciklusa A JDO különbözı objektum-állapotokat tart nyilván attól a perctıl kezdve, hogy a példány létrejön, és egészen addig a percig él, amíg nem töröltük azt. Végül a Java Virtual Machine elvégzi a szemétgyőjtögetést. Az állapotátmenetekhez szükséges metódusokat a PersistenceManager osztály szolgáltatja makepersistent (Object object), maketransientall (Collection c), deletepersistent (Object object). Az állapotváltozásokat a következı ábra mutatja: 8

11 A JDO specifikáció 10 állapotot definiál: Transient: a fejlesztı által írt konstruktorhívással létrehozott objektumok, melyek még nem perzisztensek. Még nincsen objektum azonosságuk Persistent-new: egy tranziens objektum a makepersistent() metódus hatására perzisztenssé válik. Ekkor más az objektumok rendelkeznek identitással. Persistent-dirty: minden olyan perzisztens objektum, mely megváltozott a jelenlegi tranzakció során. Hollow: egy speciális objektumállapot, azokat az objektumokat reprezentálja, melyek már benne vannak az adattárban, de még nincs értékük. Segít megbizonyosodni az objektum egyediségérıl a tranzakciók között. Persistent-clean: a példány adatai a tárolóban vannak, és az aktuális tranzakció alatt nem változott meg az értéke. Persistent-deleted: a deletepersistent() metódushívás során elıálló állapot. Egy persistent-deleted példány tranzienssé válik. Persistent-new-deleted: azok az objektumok, melyek egy tranzakción belül kerültek persistent-new állapotba és töröltük. Persistent-nontransactional: azon perzisztens objektumok, melyek értékeit már betöltöttük, de nem konzisztensek. Transient-clean: csak tranziens példány kerülhet ebbe az állapotba, akkor, ha a példány értéke nem változott meg a tranzakción belül Transient-dirty: ha egy transient-clean állapotban lévı példány értéke megváltozott, akkor kerül ebbe az állapotba. Az elsı hét állapot kötelezı módon jelen van, a másik három viszont opcionális, csak bizonyos állapotokból érhetı el, amint azt a fenti ábra is mutatja. Perzisztens osztályok megkövetelik a következıket: a mezık elérhetıek legyenek a JDO osztályok számára (public); egyes osztályok példánya nem támogatott (Például a Thread, File, Socket nem szerializálható). A JDO kétféle interfészt definiál: JDO API (javax.jdo csomagban) JDO SPI (service provider interfész a javax.jdo.spi csomagban) 9

12 Egy alkalmazás két fontosabb interfészt használ: PersistenceManagerFactory: azt az elérési pontot reprezentálja a fejlesztı számára, amellyel a PersistenceManager osztály példányai elérhetıek amiket a késıbb módosítani, szerializálni lehet. PersistenceManager: a JDO alkalmazások komponensei számára ez az elsıdleges interfész. Metódusokat szolgáltat az objektumoknak a perzisztencia kezelésére úgymint perzisztens objektumokhoz való hozzáférés, törlés az adattárból; egy objektum módosítása; és ezzel együtt automatikus objektumállapot változás. PersistenceManagerFactory és PersistenceManager elérése: Properties props = new Properties(); //1 props.put(...); //2 PersistenceManagerFactory pmf = JDOHelper.getPersistenceManagerFactory(props); //3 PersistenceManager pm=pmf.getpersistencemanager(); //4 1. A Properties osztály a tulajdonságok perzisztens halmazát (kulcs-érték párok) reprezentálja. 2. A JDO és az adattár néhány sajátosságait adhatjuk meg a put ( ) metódusban. Nézzünk meg ezek közül néhányat: ( javax.jdo.option.connectiondrivername, com.mysql.jdbc.driver ); //driver név ( javax.jdo.option.connectionurl, jdbc:mysql://localhost/jpox ); //URL ( javax.jdo.option.connectionusername, username ); //kapcsolatnév ( javax.jdo.option.connectionpassword, password ); //jelszó 3. A PersistenceManagerFactory létrehozása 4. A pmf factory PersistenceManager példánya is létrejön. Ahhoz, hogy egy JDO alkalmazást futtatni tudjunk, a következı lépéseket kell végrehajtani: 1. Osztályok létrehozása, alapértelmezett, privát konstruktorral. 10

13 2. Metaadatok megírása, és azoknak a mezıknek és osztályoknak a kiválogatása, melyeket perzisztálni kell. Azokról a csomagokról is szolgáltat információt, melyekben perzisztens osztályok vannak. Egy metaadat fájl egy osztályhoz tartozik, és a neve megegyezik az osztály nevével, csak a kiterjesztése.jdo. Ezeket a fájlokat ugyanoda kell elhelyezni, mint ahol a class fájlok vannak. Példa egy egyszerő metaadat fájlra: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE jdo SYSTEM "jdo.dtd"> <jdo> <package name="futok"> <class name="futo" identity-type="application"> </class> </package> </jdo> Az osztályokon belül megadhatjuk a mezık neveit és a kollekciókat, egy XML leírón belül pedig több osztályt is. 3. Az osztályok lefordítása a JDO Enhancer segítségével: bájtkód módosításokat végez a Java osztályokon, hogy persistent-capable osztályokká alakítsa. Ez alatt az idı alatt a javax.jdo.persistencecapable interfész hozzáadódik az osztályhoz. Tehát ha használni szeretnénk ennek az interfésznek a metódusait, nekünk nem kell implementálni a PersistenceCapable-t, hanem a fordítás után a JDO Enhancer-t kell futtatnunk, hogy elkészítse a bájtkód manipulációkat. Összességében csak a lefordított Java osztályokról és a JDO metaadat fájlról kell gondoskodnunk e lépés során. 4. Adatbázistáblák létrehozása; indexek, külsı kulcsok definiálása. Vannak olyan JDO implementációk, melyek tartalmaznak séma-eszközöket: mindezeket automatikusan generálja a JDO leíróból. 5. Az alkalmazás futtatása. 11

14 4. Perzisztencia keretrendszerek A perzisztencia keretrendszereket azon célból fejlesztették ki, hogy segítse a programozót az objektum relációs leképezések és az adat perzisztencia használatában. Nem mindig egyszerő azt eldöntenünk, hogy a feladatunk elkészítése során melyik megoldás lenne a legegyszerőbb, legmegfelelıbb. A továbbiakban bemutatásra kerülnek az egyes keretrendszerek, hogy mikor, melyiket érdemes használni, mik az elınyei, esetleg hátrányai. Néhány ismertebb keretrendszer, amikrıl szó lesz a következıkben: Hibernate Entity Enterprise Java Beans Java Persistence API TopLink 4.1. Entity Enterprise Java Beans (EJBs) Java kódok írása során az egyik legfontosabb tulajdonság a platformfüggetlenség. Az EJB-k alkalmazása mellett is teljesül a platformfüggetlenség, sıt implementáció-függetlenek is, ami azt jelenti, hogy bármely alkalmazásszerveren képesek futni. Az EJB egy olyan komponens, mely a szerver oldalon jelenik meg, egy konténerben fut, szolgáltatásokat biztosít a bean számára (tranzakciókezelés, perzisztencia, biztonsági funkciók). A kliens az EJB-vel a konténeren keresztül kommunikál. Az EJB technológia ellát minket az üzleti logikához szükséges komponensekkel. EJB konténer: az a környezet, mely közvetítı szerepet játszik a bean osztály és az EJB szerver között. Az üzleti logika: a háromrétegő adatkezelı alkalmazások középsı rétege, melynek szerepe az alkalmazás mőködési szabályainak, logikájának leírása. Adatokat mozgat és dolgoz fel a másik két réteg között. Az adatok tárolása, megjelenítése nem az ı feladata. Egy beanhez kötelezı módon tartozik egy interfész: home (saját) vagy remote (távoli). Mindkét interfész elérhetı távoli kliensekrıl. 12

15 Home interface: a bean életciklusra vonatkozó metódusait tartalmazza, például új bean létrehozása, bean törlése stb. Remote interface: az enterprise beanek azon üzleti metódusait definiálja, melyekhez a kliens hozzáfér. A java.rmi csomagban helyezkednek el. Az EJB architektúra 3 féle beant különböztet meg: entity bean: a való világot modellezi. Az adatbázisban perzisztens adatokként jelennek meg. Az entity beant egyszerre több kliens is használhatja, van egyedi azonosítója. Ezen azonosító alapján az osztály egyedeit az EJB konténer egyértelmően meg tudja határozni. Az entity beaneket a Java Persistence API váltotta fel. session bean: az alkalmazást a kliens session bean metódusok hívásával érheti el. Egyszerre csak egy klienst szolgál ki. Ha a kliens megszőnik, vagy a szerver leáll, akkor a bean is megszőnik. A session beaneknek két fajtáját különböztetjük meg: stateless és stateful. - stateless (állapot nélküli): a kliens metódushívásai között nem ıriz meg semmilyen állapotot. A metódus híváskor a bean minden példánya egyenértékő, ezért az EJB konténer kiválaszthatja a példányokat a kliensek számára. Ez az egyetlen olyan bean, mely webszolgáltatásokat implementálhat. - stateful (állapottal rendelkezı): a kliens két metódushívása között megırzi a példányváltozók állapotát. message-driven (eseményvezérelt) bean: JMS (Java Messaging Service) üzenetek kezelésére tervezték. Az eseményvezérelt bean a kliens üzenetek hatására mőködésbe lép. Amikor egy JMS üzenet célba ér, akkor az EJB konténer meghív egy messagedriven beant, és átadja neki az üzenetet. Nincs semmilyen interfésze, mert a kliensek nem hívhatják közvetlenül a beaneket ebben különbözik a másik két beantıl. Csak bean osztálya létezik. Az EJB elınye, hogy skálázható (további számítógépek hozzákapcsolása tulajdonképpen bármilyen mennyiségben), és hibatőrı. Viszont a használata nagyon sok tudást, és erıforrást igényel. 13

16 Java Naming and Directory Interface (JNDI) A JNDI távoli objektumok elérésére szolgál, függetlenül attól, hogy milyen nyelven íródtak. Minden EJB konténernek része egy JNDI katalógus. A fájlrendszerek könyvtárszerkezetére hasonlít a JNDI adatstruktúrája. Egy katalógus eléréséhez 3 dolog ismeretére van szükség: sémára, mely alatt a katalógus tárolja kontextusok listája (egy kontextus a könyvtárnévvel analóg) név: ami alatt a katalógus tárolja (egyenértékő a fájlnévvel) Egy katalóguselemet a következı módon érhetünk el: Context context = new InitialContext(); Object o = context.lookup( java:comp/env/bean ); ahol a java:comp/env/bean egy JNDI név. A Context osztály a java.naming.* csomagban helyezkedik el, és a JNDI egyik legfontosabb interfésze. A katalóguselemeknek típusa is lehet, sıt általában van is. A lookup metódus eredményét megfelelı típussá kell konvertálni, mivel az csak egy objektumreferenciát ad vissza TopLink A TopLink egy olyan objektum-relációs perzisztens Java technológia, mely az objektumorientált rendszerek és a relációs adatbázisok közötti kapcsolatot teremti meg. Az Oracle Fusion Middleware alkalmazásfejlesztı eszközkészletének egy részét képezi. Gyors adatbázis elérést/kezelést tesz lehetıvé. A TopLink akkor ideális választás, ha a rendszerünk már tartalmaz valamilyen más, alapvetı Oracle terméket. Egyéb fontosabb tulajdonsága: Lekérdezı nyelvekben gazdag: Query by Example, SQL, EJB QL. Gyorsítótárazás objektumazonosításra. A TopLink egy szabadalmaztatott termék, ezért a fejlıdése az Oracle fejlıdésétıl függ. 14

17 4.3. Java Persistence API A JPA a POJO technológián alapul: öröklés, polimorfizmus, szabványos objektum/relációs leképezés, SQL nyelvő lekérdezések támogatása. Ötletet merített a Hibernate, a TopLink, a JDO és az EJB keretrendszerekbıl. Így született meg a Java Persistence API, ami segíti a fejlesztıt a relációs adatbázis kezelését Java EE vagy Java SE alkalmazásokban. 3 lényeges részbıl áll: Entitások Persistence Unit (Perzisztencia Egység) Persistence Context (Perzisztencia Kontextus) Entitások Egyszerő Java osztályok, nincs olyan interfész, melyet kötelezı módon implementálni kell. Annotációk segítik a programozót, és a lekérdezés perzisztencia-lekérdezı nyelvvel történik. Az entitások egy API használatával érhetık el futási idıben (Entitás Manager API). Tulajdonságai: van saját vagy örökölt elsıdleges kulcsuk lehet absztrakt is szerializálható Alapvetıen kétféle perzisztens osztályt különböztetünk meg: entity és embeddable (beágyazható). Az entity osztályok minden egyes példánya egyediként jelenik meg az adattárban. Egy perzisztens osztály példánynak nincs perzisztens identitása. Entitást kétféleképpen kereshetünk: Azonosító alapján: EntityManager használatával, melyet annotációval látunk el Kritérium alapján: valamiféle egyezıséget keresünk, ezt szolgálja a Query. Beágyazható osztályoknál közvetlenül egyik sem szolgáltat eredményt. 15

18 Néhány követelmény a perzisztens osztályokhoz: Kötelezı egy argumentum nélküli konstruktor public vagy protected láthatósággal. Sem egy entity osztály, sem a metódusa nem lehet final. Lennie kell egy vagy több azonosító mezınek (elsıdleges kulcs) A verzió mezı használata nem kötelezı, de ajánlott. Arra való, hogy egy entitáson belül ugyanannak az adatbáziselemnek az értékét konkurens módon ne lehessen megváltoztatni. Típusa valamilyen egész (Long, int) vagy java.sql.timestamp lehet. Öröklıdés: a perzisztens osztályok származtathatók perzisztens és nemperzisztens osztályokból, kivétel néhány egyszerő osztály, mint például a java.lang.thread, java.net.socket - a nemperzisztens osztályok viszont perzisztens osztályokból kell, hogy származzanak. Az öröklıdési hierarchiában minden perzisztens osztálynak azonos identitással kell rendelkeznie. A perzisztens mezık állapotait a JPA kezeli. Nem megengedett static és final mezık alkalmazása. Azonban tartalmaz beépített támogatást a legtöbb egyszerő típusra. Ezeket a típusokat három kategóriába sorolhatjuk: változó, állandó és relációs típus. Állandó típus: létrejötte után már nem módosítható. A JPA a következı típusokat támogatja: primitív típusok (int, char, byte stb.); a primitív típusok csomagoló osztályai (Integer, Character, Byte stb.); java.lang.string; java.math.biginteger; java.math.bigdecimal. Változó típus: anélkül tudjuk változtatni egy mezı értékét, hogy a mezı új értéket kapna, azaz közvetlenül lehet manipulálni. Változó típusúak: java.util.date; java.util.calendar; java.sql.date; java.sql.timestamp; felsorolásos típus (Enum); entity és beágyazható típusok; java.util.collection; java.util.set; java.util.list; java.util.map. 16

19 Entitások identitása A Java kétféle objektum azonosságot különböztet meg: numerikus és kvalitatív. Numerikus egyezıség akkor áll fenn, ha a memóriában ugyanarra a példányra vonatkoznak. A kvalitatív azonosság az objektum egyenlıséget vizsgálja néhány, a felhasználó által definiált kritérium alapján. Ezzel szemben a JPA entity és perzisztens identitást különböztet meg. Az entity azt teszteli, hogy vajon két perzisztens objektum ugyanazt az állapotot reprezentálja az adattárban. Ha két azonos típusú entitás mezıértéke megegyezik, akkor a két entitás ugyanazt az állapotot képviseli az adatbázisban. Minden entitás azonosító mezıjének egyedinek kell lennie. A mezı értéke lehet primitív, primitív csomagoló, sztring, dátum, TimeStamp vagy beágyazható. Callback metódusok: Gyakran szükség van különbözı módosításra/pontosításra az objektumok életciklusának egyes állapotaiban. Ezt szolgálják a különféle callback metódusok. Minden perzisztens eseménynek van egy jelölıje, amit a híváshoz kétféleképpen definiálhatunk, annotációt helyezünk el a metódus elıtt, vagy egy XML fájlban megadjuk a metódusok listáját. A szóban forgó metódus jelölık a következık: PrePersist: ezt az annotációt használjuk, ha elsıdleges kulcsértéket akarunk tulajdonítani egy perzisztens objektumnak. Az XML leíró fájlban ezt a pre-persist elemmel jelöljük. PostPersist: egy objektum perzisztens állapotba kerülése elıtt hívjuk meg. Például képernyıfrissítés egy sor hozzáadása, vagy törlése esetén. az XML post-persist elemével egyenértékő. PostLoad: ezzel az annotációval ellátott metódust azután használjuk fel, miután az osztály minden eager fetched mezıi betöltıdtek az adatbázisból. Fetch: kétféle módban mőködik, EAGER (mohó) és LAZY (lusta). Azt mondja meg, hogy betöltésnél az adott irányban be kell-e tölteni a hivatkozott entitásokat. Eager fetch type esetén azonban elıfordul, hogy egy entitás betöltésekor a vele kapcsolatban lévı összes entitást is behúzzuk vele. PreUpdate: azelıtt használjuk fel, mielıtt az objektumok új értékeit módosítanánk az adatbázisban (flush). 17

20 PostUpdate: annotációval rendelkezı metódusok az adatbázisban történt változások mentése után lépnek mőködésbe. Ez a mővelet cache ürítésnél is fontos szerepet játszik. PreRemove: objektum törlése elıtt használhatunk ezzel a jelölıvel ellátott metódust, a perzisztens mezık elérése e metóduson belül lehetséges. PostRemove: az objektum már ki van jelölve törlésre. Egy példa arra, hogyan deklaráljunk callback public class private List<Futam> futamcollection; public void logfutodel (){... } A következı XML fájl ugyanazt jelenti, csak annotációk nélkül: <entity class="futo"> <pre-remove> logfutodel </pre-remove> </entity> Metaadatok Minden perzisztens osztály mellé kell valamilyen metaadat. Ez a metaadat a következı célokat szolgálja: 1) Perzisztens osztályok azonosítása 2) Az alapértelmezett JPA viselkedés felüldefiniálása 3) Olyan információkat ad, melyeket egy perzisztens osztállyal nem tudunk egyszerően kifejezni 18

21 A metaadat megadása történhet annotációk vagy XML leírók definiálásával, de használhatjuk a kettı keverékét is. Ha az XML metaadatot választjuk, akkor a fájlnak elérhetınek kell lennie fejlesztési és futási idıben is, és felderíthetınek kell lennie a provider számára egy konfigurációs információnak: Ezt szolgálja a META-INF könyvtárban elhelyezett persistence.xml fájl Osztályra vonatkozó metaadatok 1. annotációval vagy XML leíróval vannak jelölve 2. Identity osztály: olyan osztályoknál van rá szükség, ahol összetett kulcsérték van, és a kulcsokat eggyé kell tenni. Ekkor használjuk vagy XML-ben az ezzel egyenértékő id-classt. 3. A mapped ısosztály: nem entitás osztály. Példányait nem adhatjuk meg semmilyen lekérdezésben (sem az EntityManager sem a Query metódusaiban). Az annotáció a MappedSuperclass, az XML leíró pedig a mapped-superclass. A mapped szuperosztályok általában absztraktak. 4. Beágyazható osztály: elızi meg az public class int Cim cim; public class Cim{ int ir_szam; String varos; String utca; } 19

22 Mezı és property metaadatok A JPA a perzisztens állapot elérésére két módot ajánl fel: mezı és property alapú elérés. Mezı alapú elérés esetén az implementáció közvetlenül injektálja be az állapotot a mezıkbe, és vissza is adja a megváltozott állapotot. XML metaadat esetén az attribútum elérési típusát FIELD-re állítjuk, különben pedig csak meg kell jelölni a megfelelı annotációval az entitást. A property típusú elérést használva az adatok keresése és betöltése get és set metódusokon keresztül történik. Ez esetben az annotációt a get metódus elıtt helyezzük el, és az XML-ben az entitás elérési attribútumát PROPERTY-ként tartjuk nyilván. Minden osztály használhat akár mezı, akár property alapú elérést, de egy osztályon belül a kettı nem keveredhet. Ha egy osztálynak van ısosztálya, akkor az alosztálynak ugyanazt a fajta elérést kell alkalmazni. Típusai: 1) Transient: a nem perzisztens annotációval vannak ellátva, az XML elem a transient. Nincs paramétere. 2) jelöljük az azonosító mezıt, különben id-vel. 3) Generated Value: az Id annotáció mellett lehetıség van megadni, hogy az azonosító mezıt hogyan generáljuk. Ezzel az annotációval (GeneratedValue) egyedi azonosítót rendelhetünk a mezıkhöz, ehhez a következı két paramétert adhatjuk meg (vagy csak az egyiket, vagy mindkettıt egyszerre): GenerationType strategy: egy Enum érték szemlélteti, hogy hogyan történjen a mezı automatikus értékének létrehozása. Megjegyezném, hogy ezek az értékek csak egész típusúak lehetnek. Az Enumok a következık: GenerationType.AUTO: definiál egy értéket. Ha nem adunk meg semmilyen típust, akkor ez az alapértelmezett. GenerationType.IDENITY: az adatbázis jelöli ki az értéket. GenerationType.SEQUENCE: az adatbázis felügyel egy számlálót, és ez alapján történik az elsıdleges kulcsérték meghatározása. GenerationType.TABLE: az aktuális adattáblát használja fel az egyediség megbizonyosodására. 20

23 String generator: egy elsıdleges kulcs generátort definiál, melyre a nevével lehet hivatkozni. Több paraméter is megadható, de ezek közül csak a név megadása kötelezı, aminek egyedinek kell lennie. Ha a strategy be van állítva, de a generator nincs, akkor a JPA alapértelmezést használ (, azaz strategy=generationtype.auto és generator= ). A könnyebb megértés érdekében tekintsünk meg egy public class Address name="addressgenerator", // a generátor név table="id_genertor", // a generált id-ket tároló tábla pkcolumnname="generator_key", // a PK oszlop neve pkcolumnvalue="address_id", //a PK értéke a generátor táblában allocationsize=1) //az azonosítók (strategy=table, generator="addressgenerator") public int id;... } 4) Embedded Id: egy entitást akkor látunk jelöléssel, ha összetett kulccsal rendelkezik. 5) Version: szerepe, hogy a merge mővelet idején és az optimista konkurenciavezérléskor biztosítsuk az entitás sértetlenségét. 6) Basic: az adatbázis oszlopainak az egyik legegyszerőbb leképezési módja Ezt az annotációt a következı típusú perzisztens mezıkre lehet alkalmazni: primitív típusok, primitív csomagolótípusok, java.lang.string, java.math.bigdecimal, java.math.biginteger, byte[], Byte[], char[], Character[], java.util.calendar, java.util.date, java.sql.date, java.sql.timestamp, Enum és a Serializable típusok. Két paramétere lehet: FetchType fetch és boolean optional. A FetchType mód lehet LAZY vagy EAGER a kettı közötti különbség már ismertetésre került korábban. A másik paraméter azt mondja meg, hogy a mezı típus lehet-e null vagy sem. 7) Embedded: egy beágyazott mezı az adatbázis rekordjának részeként jelenik meg. Beágyazható típusok jelölıje lehet 21

24 8) Order By: Ha szeretnénk a mezık valamilyen szintő rendezettségét elérni, akkor annotációval érhetjük el. Lehet paraméter nélküli, ekkor elsıdleges kulcs szerint rendez alapértelmezettként, de megadhatunk paramétert, ezen belül is azt, hogy növekvı (ASC) esetleg csökkenı (DESC) formában rendezze az adatokat ha hiányzik az ASC vagy DESC, akkor növekvı sorrendben listáz. Több paramétert is megadhatunk, ebben az esetben elıször az elsı paraméter szerint rendez, majd a második szerint és így tovább. 9) Map Key: OneToMany és ManyToOne kapcsolatok esetén értelmezett. Az egymással kapcsolatban álló entitások formalizálják a map értékeit. A MapKey annotáció kijelöli azt a mezıt, melyet használni kíván kulcsként. A paraméter a String name, használata opcionális. 10) Perzisztens mezık: A static, transient, final mezık nem perzisztensek. primitív típusok, primitív csomagolók, String, byte[], Byte[], char[], Character[], BigDecimal, BigInteger, Date, Calendar, Timestamp és néhány Serializable típus perzisztens. A beágyazható típusok perzisztensek. Minden egyéb típus nemperzisztens Entitások relációja A relációkat kétféleképpen tudjuk csoportba sorolni, számosság és a kapcsolat iránya szerint. 1) Számosság: egyik illetve másik oldalról hány egyed vesz részt a kapcsolatban. Négy különbözı számosságot definiál a JPA: 1-1, 1-több, több-1 és a több-több. A használata csak a List, Collection, Set, Map típusoknál támogatott. 2) Irány: beszélhetünk egy- vagy kétirányú kapcsolatról. A kétirányú kapcsolat kezelése az alkalmazás feladata. Ebben az estben van egy tulajdonos és egy inverz oldal. A tulajdonos oldal egyenértékő az elsıdleges kulccsal, az inverz oldalnak pedig a tulajdonos oldalra valamilyen módon hivatkoznia kell. 22

25 @OneToOne (1-1) Egy one-to-one kapcsolatnál három estet különböztetünk meg: az asszociált entitásoknak ugyanaz az elsıdleges kulcsa; egy külsı kulcs tartozik valamelyik entitáshoz (a külsı kulcsnak egyedinek kell lennie); létezik egy asszociációs tábla, mely tárolja a kapcsolatot a két entitás között. Az elsı esetben közös kulcsot Ez az annotáció egy kulcs oszlopot specifikál, amit külsı kulcsként használunk, hogy kapcsolódni tudjunk a másik táblához. Paraméterként megadhatjuk a tábla elsıdleges kulcs oszlopának a nevét (name= ), és a kapcsolandó tábla elsıdleges kulcs oszlopát (referencedcolumnname= ). Persze ez nem kötelezı, csak egy lehetıség. Egy one-to-one kapcsolatot szemléltethetünk egy személy-személyigazolványszám közötti viszonnyal, ugyanis egy személyhez egy személyi szám tartozik és public class public Long getid() { return id; PrimaryKeyJoinColumn public SzemIg getszemig() { return szemig; } public class SzemIg implements public Long getid() { } } 23

26 A másik esetben külsı kulcson keresztül kapcsolódnak a public class Szemely implements Serializable JoinColumn (name=szemig_fk) public SzemIg getszemig() { return szemig; } public class (mappedby= szemig ) public Szemely getszemely() { } } A Szemely tábla a SzemIg táblához külsı kulcson keresztül kapcsolódik, ezt jelöli megadott szemig_fk név. A JoinColumn mindig a tulajdonos oldalon van definiálva. Emellett az inverz oldalon a mappedby birtokolja a kapcsolatot. A harmadik lehetıség az asszociációs tábla: paramétereként megadható ennek a táblának a neve, egy joincolumns, mely a tulajdonos oldali tábla külsı kulcsát jelöli, és egy inversejoincolumns, ami az inverz tábla külsı public class Szemely implements Serializable (cascade = JoinTable (name = SzemelySzemIg, joincolumns (name = szemely_fk ) inversejoincolumns (name = szemig_fk )) public SzemIg getszemig() { return szemig; } public class (mappedby= szemig ) public Szemely getszemely() { } } 24

27 @ManyToOne (több-1) reláció egy egyirányú kapcsolatot reprezentál egy másik entitással, feltüntetve a külsı kulcsot public class Futam implements Serializable (name = (optional = false) public Futo getfuto() { return futo; } } A many-to-one kapcsolatnak ugyanolyan paraméterei lehetnek, mint a one-to-one-nak, kivéve a mappedby. A targetentity paraméterrel leírhatjuk a cél entitás nevét. Általában nem szükséges megadni, csak ha egy interfészt visszatérési típusként akarunk használni (targetentity = FutoImp.class). Asszociációs táblán keresztül is le lehet képezni a kulcsokat, mint ahogyan azt láttuk a oneto-one reláció (1-több) Egy one-to-many kapcsolat lehet egy- vagy kétirányú. Kétirányú kapcsolat: A tulajdonos oldalon a one-to-many kapcsolat a következı módon van annotációval (mappedby = ). Egy példa arra, hogyan annotáljuk a propertyket, amikor a one-to-many kapcsolat az inverz oldalon van: public class Futo (mappedby = "futo") private Collection<Futam> getfutam() { } 25

28 @Entity public class Futam (name = public Futo getfuto() { return futo; } } A Futo osztály kétirányú one-to-many kapcsolatban van a Futam osztállyal, a mappedby által megnevezett futo property-n keresztül. Ha viszont nem az inverz oldalon van a one-tomany kapcsolat, akkor a mappedby paramétert el kell távolítanunk, és az inverz oldalon insertable és updatable paramétereit false-ra kell állítani. Ez a megoldás külön UPDATE-ek megírását vonja maga után. Egyirányú kapcsolat: Az egyik lehetıség egy külsı kulcs létrehozása a tulajdonos (name= futo_id ) De e helyett inkább join table használata javasolt. A OneToOne kapcsolatnál már láthattuk, hogy hogyan kell létrehozni egy join table-t, azonban ekkor egy kollekció annotálására alkalmazzuk. Ha csak adjuk meg a tulajdonos oldalon, akkor létrejön egy join table, alapértelmezett névvel (a két tábla neve között _ (több-több) A ManyToMany reláció egy- vagy kétirányú kapcsolatot biztosít az egyedek egy kollekciójához. Az adatbázisban ezt a join table reprezentálja. name paramétere specifikálja a kapcsolótábla nevét, ha viszont nincs megadva, akkor a tulajdonos és az inverz tábla nevébıl áll össze a név. 26

29 a kapcsolódó oszlopok tömbjét definiálja megmondja az inverz osztály oszlopainak tömbjét. Az inverz oldalon a mappedby argumentum hivatkozik a másik oldali property nevére, ha a kapcsolat public (name="hallgato_oktato", joincolumns (name="hallg_id", referencedcolumnname="id"), inversejoincolumns (name="oktato_id", referencedcolumnname="id") ) public Set getoktatok() { return oktatok; } public class (mappedby = "oktatok") public Set gethallgatok() { return hallgatok; } } Persistence Unit A csomagolás és a telepítés alapegysége. Entitások és a hozzájuk kapcsolódó osztályok halmaza. O/R mapping információk leírása: Java nyelvő annotációkkal és/ vagy XML fájlokkal Az entitások közötti relációk, lekérdezések hatáskörét definiálja persistence.xml: konfigurációs információ 27

30 Persistence Context Egy perzisztencia unithoz tartozó entitás példányok halmaza, ezen keresztül kezeljük az entitások és az adatbázis közötti kapcsolatot. A perzisztencia kontextus injektálás segítségével elérhetı (például Session private EntityManager em; néhány paramétere: unitname: ha több Unit van a persistence.xml-ben, akkor meg kell adni type: egy perzisztencia kontextus élettartama lehet az egész tranzakcióra kiterjedı (TRANSACTION) vagy több tranzakciót is átfogó (EXTENDED). Az élettartamot vagy a konténer vagy az alkalmazás menedzseli. A TRANSACTION az alapértelmezett. Entitáskezelı API A Persistence Context és az entitások életciklusának kezelésére szolgál Az életciklus állapotait a következı ábra szemlélteti: 28

31 New: létrejön egy új entitás, ekkor még nem perzisztens, és nincs menedzselt állapotban. Persist: menedzselt állapotba kerül az entitás. Az adatbázisba a legelsı flush vagy commit esetén kerül. Ha detached állapotban hívjuk meg a persist (Object o) metódust, akkor IllegalArgumentException-t kapunk. Remove: entitás törlése, commit vagy flush után az adatbázisból is. Detached állapot esetén szintén IllegalArgumentException. Refresh: az entitás állapota frissül az adatbázisból. Ez a mővelet hosszú futású tranzakcióknál hatékony, ugyanis fennáll az adatok elavulásának a veszélye. Detach: a Persistence Context törlése vagy befejezıdése esetén az entitások leválnak a kontextusból. Merge: a merge metódus egy lekapcsolódott entitás állapotának másolatával tér vissza, és ez a másolat egy menedzselt entitás. Ennek állapota megegyezik az eredeti állapotával. Lock: zárolja a paraméterként megadott entitást a megadott módon. Két zárolási módot különböztetünk meg, ezek a javax.persistence.lockmodetype enumjai: READ és WRITE. READ: más tranzakciók konkurens módon olvashatják ugyanazt az objektumot, de nem írhatják. WRITE: konkurens módon nem olvashat és írhat másik tranzakció egy objektumot Lekérdezések (Query) Statikus, névvel azonosítható lekérdezések: Java metaadattal vagy XML fájllal definiálható, ilyen például ( name="findallfutowithname", query="select f FROM Futo f WHERE f.name LIKE :futoname" ) A name és a query paramétereket kötelezı megadni. Itt definiáljuk a lekérdezésünk feltételeit. 29

32 A public EntityManager em;... futok = em.createnamedquery("findallfutowithname").setparameter("futoname", "Valaki").getResultList(); Egy EntityManager példányt kell létrehozni, majd a createnamedquery paramétereként megadjuk meghatározott nevet. Az EntityManager interfész metódusai tartják a kapcsolatot és kommunikálnak a perzisztencia kontextussal. Dinamikus lekérdezések: Java Persistence Query Language vagy natív SQL nyelven public Query createquery (String query): a Query objektumok arra valók, hogy megtaláljuk a keresett entitásokat valamilyen kritérium alapján. A metódus létrehoz egy query sztringet a JPQL-nek megfelelıen. Natív SQL: public Query createnativequery (String sql): sql utasításokat adunk meg sztringként. Keresés elsıdleges kulcs alapján: public Futo keresfuto (Object id) { return em.find (Futo.class, id); } A Query fontosabb metódusai: List getresultlist(): végrehajt egy SELECT utasítást, és visszatér az általa visszaadott eredménynek listájával (List). Object getsingleresult(): a SELECT utasítás egyetlen egy eredménnyel tér vissza int executeupdate(): eleget tesz egy update vagy egy delete utasításnak. Az int típusú visszatérési érték azt jelzi, hogy hány entitás lett módosítva vagy törölve. 30

33 Java Persistence Query Language (JPQL) Az SQL-hez hasonló, saját lekérdezı nyelv. Az EJB QL módosítása néhány bıvítéssel: törlést, módosítást nem kell egyesével elvégezni, létezik az ún. többes törlés/ módosítás GROUP BY, HAVING subquery-k (ALSELECT) projekciós lista (csak bizonyos attribútumokat adjon vissza) egy SELECT-ben visszaadott oszlopokat egy általunk definiált objektumként kaphatjuk meg Leszármaztatás Az entitások származhatnak más entitásokból - akár konkrét, akár absztrakt -, közönséges Java osztályból és mapped ısosztályból (@MappedSuperclass). A JPA a következı három öröklési módot támogatja: Table per Class: tábla tartozik minden konkrét osztályhoz, vagyis külön tábla szükséges minden altípushoz. Emellett minden tábla tartalmazza a szuperosztály attribútumait is. Normalizált megoldás, de a polimorfizmus támogatása nehézkes. Single Table: egy tábla egy öröklési hierarchiához tartozik, azaz a szuper- és alosztályok összes attribútuma egy táblába vannak leképezve, a példányok egy diszkriminátor által vannak megkülönböztetve. Elınye, hogy nem kell join, és a polimorfizmust is támogatja, viszont nagyobb osztályhierarchia esetén túlzsúfolt lesz a tábla. Az osztály hierarchia legfelsı szintjén meg kell adni az osztálydefiníció elıtt a ( strategy=inheritancetype.single_table ( name= oszlop_név ) Továbbá minden osztály elıtt a típusra utaló ( osztálynév ) Joined Subclass: külön tábla gyermekosztályonként. Az ısosztályban definiált oszlopok egy táblában, a gyermekosztályban definiált oszlopok pedig külön táblában vannak, 31

34 továbbá kell egy külsı kulcs az ısre Nincsenek fölösleges oszlopok, azonban sok join ronthatja az átláthatóságot. Az osztálydefiníciót ( strategy=inheritancetype.joined ) elızi meg. 32

35 4.4. Hibernate A Hibernate az objektum perzisztenciát biztosító eszközrendszer Java és.net alkalmazások esetén. Lehetıvé teszi perzisztens osztályok létrehozását, melyek objektumorientált módon mőködnek, vagyis megengedett az öröklıdés, a polimorfizmus, a kompozíció, az asszociáció és a kollekciók használata. A HQL (Hibernate Query Language) a Hibernate hordozható, saját lekérdezı nyelve. A HQL az SQL nyelv kiterjesztése. A lekérdezéseket megfogalmazhatjuk mind HQL, mind SQL nyelven. Továbbá a Hibernate rendelkezik a Criteria - mely a fejlesztınek megadja azt a lehetıséget, hogy objektum-orientált módon készítse el a lekérdezéseit - és az Example keretrendszerrel. Alrendszerei közül tekintsünk meg néhányat: Hibernate Core: Elınyei: SQL kód elıállítás, megoldja helyettünk az objektum konverziót és a JDBC eredményhalmazok kezelését. Független keretrendszer, minden JavaEE alkalmazásszerveren mőködik. Egy egyszerő megoldás a perzisztencia megvalósítására, a hozzá tartozó egyszerő API-vel. A leképezett metaadatok XML fájlokban tárolódnak. Egy XML fájlban metaadatok segítségével definiálható az adatbázis tábla és a perzisztens objektum közötti kapcsolat. Hibernate Annotations: A JDK 5-tıl létezik. A Java kódban elhelyezett annotációk alkalmazásával az objektum relációs leképezés megvalósítása. Az egyszerő Hibernate XML mapping fájlok mellett egy kiegészítı megoldás. A metaadatok a kóddal együtt egy Java fájlba vannak egyesítve, azért, hogy a felhasználót segítsék a tábla struktúra megértésében. Ha a hordozhatóság fontos a számunkra, akkor a rendszer lehetıséget nyújt standard JPA, és fejlettebb Hibernate annotációk alkalmazására. Hibernate Entity Manager: implementálja a perzisztencia kezelı API-t (JPA), a perzisztencia lekérdezı nyelvet (Java Persistence Query Language), a java perzisztencia objektum életciklusra vonatkozó szabályokat, a konfigurációt és csomagolást. Ezek mellett használható a Hibernate natív API, natív SQL, és a JDBC, ha szükséges. 33

36 Hibernate Validator: adatbázis sémára vonatkozó megszorítások írhatók le, hogy mielıtt a Hibernate mentene egy változtatást, ellenırzi az entitás érvényességét, azaz megfelelıek-e a módosítások. Ilyen lehet például amikor is nem adtatunk meg null értéket, vagy mikor ellenırizzük az cím érvényességét stb. NHibernate:.NET platformra készült. A perzisztens.net objektumok kezelését az XML-ben leírt metaadatok valósítják meg. A perzisztens osztályoknak nem szükséges semmilyen interfészt implementálni vagy öröklıdnie valamilyen osztályból. Támogatja az OO paradigma használatát, nyílt forráskódú. Automatikus SQL generálás az objektumok betöltésére, mentésére A Hibernate felépítése A Hibernate architektúrának három fı komponense van: Kapcsolatok kezelése: cél a hatékony adatbázis kapcsolat kezelése, ugyanis egy adatbázis kapcsolat sok erıforrást igényel. Tranzakciók kezelése: egy idıben több adatbázis mővelet is végrehajtódhat. O/R mapping: adat reprezentációs leképezési technológia (objektum modellbıl relációs adatmodell). A Hibernate-nek ezt a részét használjuk a rekordod manipulálására az adatbázisban. (SELECT, INSERT, UPDATE, DELETE) 34

37 Az architektúra fajtái: a) Magas szintő architektúra: Az ábrán látható, hogy a Hibernate használ egy adatbázist, és konfigurációs adatokat. A Java osztályok a táblát reprezentálják az adatbázisban, és a példányszintő változók pedig a tábla sorait. A Hibernate különbözı operációkat hajt végre az adatbázison a metaadatok és a konfigurációs beállítások segítségével, objektumokat ad át az alkalmazás számára, vagy az általa létrehozott objektumokat menti az adattárba. A lényeg, hogy a fizikai adatbázist elrejti elılünk. b) Lite architektúra: gondoskodik saját JDBC kapcsolatról, és kezeli a tranzakciókat. 35

38 c) Full cream architektúra: mindhárom komponenst használja Tekintsük meg közelebbrıl az ábrán látható objektumok definícióit: org.hibernate.sessionfactory: az adatbázis-leképezés tárolására kialakít egy szál-biztos, azaz állandó cache-t. Session-öket hoz létre, és kliens a ConnectionProvider felé. Nyilvántarthat egy másodlagos adat cache-t, melyek újrafelhasználhatóak a tranzakciók között. org.hibernate.session: a kliens és a perzisztens tároló között egy párbeszédet reprezentáló rövid élető objektum. Mikor adatbázis módosításokat akarunk végezni, a Session objektumok létrehoznak egy Transaction típusú objektumot. Ezek az objektumok reprezentálják az adatbázison elvégzett munkát. A perzisztens objektumok számára fenntart egy cache-t. Perzisztens objektumok: rövid élető objektum, mely megvalósítja az üzleti funkciókat és a perzisztens állapotot. Ezek lehetnek Java Beanek vagy egyszerő Java objektumok, melyek egy Session-höz tartozhatnak csak. Ha a Session bezárul, az objektum elérhetıvé válik az alkalmazás többi rétege számára. Tranziens objektumok: Egy perzisztens osztály azon példányai, melyek adott idıben nincsenek kapcsolatban egy Session-nel sem. Ilyen például az az objektum, melyet egy olyan Session hozott létre, mely már lezárásra került, vagy amit az alkalmazás létrehozott és még nincs perzisztens állapotban. 36