specifikációként a Java Persistence API a perzisztenciával foglalkozik, ami lazán minden olyan mechanizmust jelent, amellyel a Java objektumok túlélik az őket létrehozó alkalmazási folyamatot. Nem minden Java objektumot kell tartani, de a legtöbb alkalmazás továbbra is kulcsfontosságú üzleti objektumokat tartalmaz. A JPA specifikáció segítségével meghatározhatja, hogy mely objektumokat kell tartani, illetve hogy ezeket az objektumokat hogyan kell tartani a Java alkalmazásokban.
önmagában a JPA nem eszköz vagy keretrendszer; inkább meghatározza azokat a fogalmakat, amelyeket bármely eszköz vagy keretrendszer végrehajthat. Míg a JPA objektum-relációs leképezés (ORM) modellje eredetileg Hibernáltra alapult, azóta fejlődött. Hasonlóképpen, míg a JPA-t eredetileg relációs / SQL adatbázisokhoz szánták, néhány JPA implementációt kiterjesztettek a NoSQL datastores használatához. Egy népszerű keretrendszer, amely támogatja a JPA-t a NoSQL-vel, az EclipseLink, a JPA 2.2 referencia implementációja.
JPA és Hibernate
összefonódott történetük miatt a Hibernate és a JPA gyakran összefolyik. Azonban, mint a Java Servlet specifikáció, JPA szült sok kompatibilis eszközök és keretek; Hibernate csak egy közülük.
A Gavin King által kifejlesztett, 2002 elején kiadott Hibernate egy ORM könyvtár Java számára. Király kifejlesztett Hibernate alternatívájaként entitás bab perzisztencia. A keret annyira népszerű volt, és annyira szükség volt akkoriban, hogy számos ötletét elfogadták és kodifikálták az első JPA specifikációban.
ma a Hibernate ORM az egyik legérettebb JPA implementáció, amely még mindig népszerű lehetőség az ORM számára Java-ban. Hibernált ORM 5.3.8 (az írás jelenlegi verziója) végrehajtja a JPA 2.2-t. Ezenkívül a Hibernate eszközcsaládja olyan népszerű eszközöket is tartalmaz, mint a Hibernate Search, a Hibernate Validator vagy a Hibernate OGM, amely támogatja a NoSQL domain-modell perzisztenciáját.
mi a Java ORM?
míg a végrehajtásban különböznek, minden JPA implementáció valamilyen ORM réteget biztosít. Ahhoz, hogy megértsük a JPA és JPA-kompatibilis eszközök, meg kell, hogy egy jó felfogni ORM.
Object-relational mapping egy feladat-az egyik, hogy a fejlesztők jó ok arra, hogy ne csinál kézzel. Egy olyan keretrendszer, mint a Hibernate ORM vagy az EclipseLink kodifikálja ezt a feladatot egy könyvtárba vagy keretrendszerbe, egy ORM rétegbe. Az alkalmazás architektúrájának részeként az ORM réteg felelős a szoftverobjektumok átalakításának kezeléséért, hogy kölcsönhatásba lépjen a relációs adatbázis táblázataival és oszlopaival. Java-ban az ORM réteg átalakítja a Java osztályokat és objektumokat úgy, hogy azok relációs adatbázisban tárolhatók és kezelhetők legyenek.
alapértelmezés szerint a megmaradó objektum neve lesz a táblázat neve, a mezők pedig oszlopokká válnak. A táblázat beállítása után minden táblázat sor megfelel egy objektumnak az alkalmazásban. Az objektum leképezése konfigurálható, de az alapértelmezett értékek általában jól működnek.
az 1. ábra szemlélteti a JPA és az ORM réteg szerepét az alkalmazásfejlesztésben.
1.ábra. JPA és az ORM réteg
a Java ORM réteg
beállítása amikor új projektet állít be a JPA használatához, be kell állítania a datastore és a JPA szolgáltatót. Beállítja a datastore csatlakozót, hogy csatlakozzon a kiválasztott adatbázishoz (SQL vagy NoSQL). A JPA szolgáltatót is megadhatja és konfigurálhatja, amely olyan keretrendszer, mint a Hibernate vagy az EclipseLink. Miközben manuálisan konfigurálhatja a JPA-t, sok fejlesztő úgy dönt, hogy a Spring out-of-the-box támogatását használja. Lásd a” JPA installation and setup ” című részt, amely bemutatja mind a kézi, mind a Rugóalapú JPA telepítést, valamint a telepítést.
adat perzisztencia Java
programozási szempontból az ORM réteg egy adapterréteg: az objektumgráfok nyelvét az SQL és relációs táblák nyelvéhez igazítja. Az ORM réteg lehetővé teszi az objektumorientált fejlesztők számára, hogy olyan szoftvert készítsenek, amely továbbra is fennáll az adatok nélkül, anélkül, hogy elhagyná az objektumorientált paradigmát.
amikor JPA-t használ, létrehoz egy térképet a datastore-ról az alkalmazás adatmodell objektumaira. Ahelyett, hogy meghatározná az objektumok mentésének és lekérésének módját, definiálja az objektumok és az adatbázis közötti leképezést, majd meghívja a JPA-t, hogy azok megmaradjanak. Ha relációs adatbázist használ, akkor az alkalmazás kódja és az adatbázis közötti tényleges kapcsolat nagy részét a JDBC, a Java Database Connectivity API kezeli.
specifikációként a JPA metaadat-kommentárokat ad meg, amelyeket az objektumok és az adatbázis közötti leképezés meghatározásához használ. Minden JPA implementáció saját motort biztosít a JPA annotációkhoz. A JPA spec is biztosítja a PersistanceManager vagy EntityManager, amelyek a legfontosabb érintkezési pontok a JPA rendszer (ahol az üzleti logikai kód megmondja a rendszernek, hogy mi köze a leképezett objektumok).
hogy mindez konkrétabb legyen, fontolja meg az 1. listát, amely egy egyszerű adatosztály a zenész modellezéséhez.
lista 1. Egy egyszerű adatosztály Java
a Musician osztály Listing 1 használják az adatok tárolására. Tartalmazhat primitív adatokat, például a név mezőt. Más osztályokhoz is kapcsolódhat, mint például a mainInstrumentés a performances.
Musician ” oka, hogy adatokat tartalmaz. Ezt a fajta osztályt néha DTO-nak vagy adatátviteli objektumnak nevezik. A dtos a szoftverfejlesztés közös jellemzője. Miközben sokféle adatot tárolnak, nem tartalmaznak üzleti logikát. A folyamatos adatobjektumok mindenütt jelen vannak a szoftverfejlesztésben.
adatmegőrzés JDBC
a Musician osztály példányának relációs adatbázisba mentésének egyik módja a JDBC könyvtár használata. A JDBC egy absztrakciós réteg, amely lehetővé teszi az alkalmazás számára az SQL parancsok kiadását anélkül, hogy a mögöttes adatbázis megvalósítására gondolna.
Listing 2 megmutatja, hogyan lehet továbbra is fennállnak aMusician osztály segítségével JDBC.
lista 2. JDBC behelyezése rekord
a kód Listing 2 meglehetősen önálló dokumentálása. AgeorgeHarrison objektum bárhonnan származhat (front-end submit, külső szolgáltatás stb.), azonosítója és névmezői vannak beállítva. Az objektum mezőit ezután egy SQL insert utasítás értékeinek megadására használják. (A PreparedStatement osztály része a JDBC, amely egy módja annak, hogy biztonságosan alkalmazni értékeket egy SQL lekérdezés.)
míg a JDBC lehetővé teszi a kézi konfigurációval ellátott vezérlést, ez nehézkes a JPA-hoz képest. Az adatbázis módosításához először létre kell hoznia egy SQL lekérdezést, amely a Java objektumról leképezi a relációs adatbázis tábláit. Ezután módosítania kell az SQL-t, amikor egy objektum aláírása megváltozik. A JDBC, fenntartása az SQL válik feladat önmagában.
adat perzisztencia a JPA
most fontolja meg a 3. listát, ahol továbbra is fennáll a Musician osztály a JPA használatával.
lista 3. George Harrison JPA
Musician georgeHarrison = new Musician(0, "George Harrison");musicianManager.save(georgeHarrison);Listing 3 helyettesíti a kézi SQL Listing 2 egy sorral, session.save(), amely arra utasítja a JPA-t, hogy tartsa fenn az objektumot. Ettől kezdve az SQL konverziót a keretrendszer kezeli, így soha nem kell elhagynia az objektumorientált paradigmát.
metaadatok megjegyzései a JPA
– ben a 3.listában szereplő varázslat egy konfiguráció eredménye, amelyet a JPA megjegyzései segítségével hoznak létre. A fejlesztők kommentárokkal tájékoztatják a JPA-t, hogy mely objektumokat kell tartani, és hogyan kell őket tartani.
A 4. lista aMusician osztályt mutatja egyetlen JPA megjegyzéssel.
4. A JPA @ Entity annotation
@Entitypublic class Musician { // ..class body}az állandó objektumokat néha entitásoknak nevezik. A @Entity egy olyan osztályhoz csatolása, mint a Musician tájékoztatja a JPA-t, hogy ezt az osztályt és tárgyait fenn kell tartani.
konfigurálása JPA
mint a legtöbb modern keretek, JPA magában kódolás egyezmény (más néven convention over configuration), amelyben a keret egy alapértelmezett konfiguráció alapján az iparág legjobb gyakorlat. Például egy Musician nevű osztály alapértelmezés szerint a Musician nevű adatbázistáblához lenne leképezve.
a hagyományos konfiguráció időmegtakarító, sok esetben elég jól működik. Az is lehetséges, hogy testre a JPA konfiguráció. Példaként használhatja a JPA @Tableannotációt a táblázat megadásához, ahol a Musician osztályt kell tárolni.
5. A JPA @ Table annotation
@Entity@Table(name="musician")public class Musician { // ..class body}Listing 5 azt mondja a JPA-nak, hogy tartsa fenn az entitást (Musician osztály) a musician táblázathoz.
elsődleges kulcs
a JPA-ban az elsődleges kulcs az adatbázis egyes objektumainak egyedi azonosítására használt mező. Az elsődleges kulcs hasznos a más entitásokkal kapcsolatos tárgyak hivatkozásához. Ha egy objektumot egy táblázatban tárol, akkor azt a mezőt is megadja, amelyet elsődleges kulcsként kell használni.
a 6. felsorolásban elmondjuk a JPA – nak, hogy milyen mezőt kell használni Musicianelsődleges kulcsaként.
6. Az elsődleges kulcs megadása
@Entitypublic class Musician { @Id private Long id;ebben az esetben a JPA @Id annotációt használtuk a id mező Musician‘s elsődleges kulcs megadásához. Alapértelmezés szerint ez a konfiguráció feltételezi, hogy az elsődleges kulcsot az adatbázis állítja be-például amikor a mező automatikusan növekszik az asztalon.
a JPA támogatja az objektum elsődleges kulcsának létrehozására szolgáló egyéb stratégiákat. Az egyes mezőnevek megváltoztatására vonatkozó megjegyzésekkel is rendelkezik. Általánosságban elmondható, hogy a JPA elég rugalmas ahhoz, hogy alkalmazkodjon a szükséges perzisztencia leképezéshez.
CRUD operations
miután leképezett egy osztályt egy adatbázis táblára, és létrehozta az elsődleges kulcsot, mindent megtalál, amire szüksége van az adott osztály létrehozásához, letöltéséhez, törléséhez és frissítéséhez az adatbázisban. A session.save() hívás létrehozza vagy frissíti a megadott osztályt, attól függően, hogy az elsődleges kulcs mező null-e, vagy az en meglévő entitásra vonatkozik. A entityManager.remove() hívás törli a megadott osztályt.
entitás kapcsolatok JPA
egyszerűen egy primitív mezővel rendelkező objektum megtartása csak az egyenlet fele. A JPA képes kezelni az entitásokat egymással kapcsolatban is. Négyféle entitás kapcsolat lehetséges mind a táblázatokban, mind az objektumokban:
- egy-sok
- sok-egy
- sok-sok
- egy-egy
minden típusú kapcsolat leírja, hogy egy entitás hogyan kapcsolódik más entitásokhoz. Például aMusician entitásnak lehet egy-sok kapcsolata aPerformance-val, egy olyan gyűjtemény által képviselt entitással, mint például aList vagySet.
Ha a Musician tartalmazza az a Band mezőt, akkor ezeknek az entitásoknak a kapcsolata sok-egy lehet, ami azt jelenti, hogy a Musicians az egyetlen Band osztály. (Feltételezve, hogy minden zenész csak egyetlen zenekarban játszik.)
If Musician tartalmazza a BandMates mezőt, amely sok-sok kapcsolatot jelenthet más Musician entitásokkal.
végül,Musician lehet, hogy egy-egy kapcsolata aQuote entitás, használt, hogy képviselje a híres idézet:Quote famousQuote = new Quote().
kapcsolattípusok meghatározása
a JPA minden kapcsolat-leképezési típusához kommentárokat tartalmaz. A 7. felsorolás azt mutatja, hogyan lehet a Musician és Performances.
7.felsorolás közötti egy-egy kapcsolatot kommentálni. Egy-egy kapcsolat kommentárja
egy dolog, amit észre kell venni, hogy a@JoinColumn elmondja a JPA-nak, hogy a Teljesítménytáblázat melyik oszlopa fogja leképezni aMusician entitást. Minden teljesítmény lesz társítva egyetlen Musician, amely nyomon követi ezt az oszlopot. Ha a JPA betölti a Musician vagy a Performance – t az adatbázisba, akkor ezt az információt használja az objektumgráf feloldásához.
stratégiák lekérése a JPA
– ben amellett, hogy tudjuk, hol kell elhelyezni a kapcsolódó entitásokat az adatbázisban, a JPA-nak tudnia kell, hogyan szeretné betölteni őket. A stratégiák lekérése mondja meg a JPA-nak, hogyan kell betölteni a kapcsolódó entitásokat. Objektumok betöltésekor és mentésekor a JPA keretrendszernek biztosítania kell az objektumgráfok kezelésének módját. Például, ha a Musician osztálynak van egy bandMate mező (mint látható, a Lista 7), terhelés george okozhat az egész Zenész táblázat betöltése az adatbázisból!
amire szükség van, az a képesség, hogy meghatározzuk a kapcsolódó entitások lusta betöltését-természetesen felismerve, hogy a JPA kapcsolatai buzgóak vagy lusták lehetnek. Használhatja a kommentárok, hogy testre a elragadó stratégiák, de JPA alapértelmezett konfigurációs gyakran működik, a dobozból, változtatás nélkül:
- Egy-a-sokhoz: Lusta
- Sok-az-egyhez: Lelkes
- sok-Sok: Lusta
- egy-Egy: Lelkes
JPA üzembe helyezési
majd befejezésül egy gyors pillantást telepítését, beállítását JPA a Java-alkalmazásokat. Erre a bemutatóra fogom használni EclipseLink, a JPA referencia végrehajtása.
a JPA telepítésének általános módja egy JPA szolgáltató bevonása a projektbe. A 8. felsorolás azt mutatja, hogy az EclipseLink függőségként szerepelne a Maven pom.xml fájlban.
8. Tartalmazza EclipseLink mint Maven függőség
org.eclipse.persistenceeclipselink2.5.0-RC1akkor is meg kell, hogy tartalmazza az Illesztőprogram az adatbázis, amint az a lista 9.
9. Maven függőség egy MySql csatlakozóhoz
mysqlmysql-connector-java5.1.32 ezután el kell mondania a rendszernek az adatbázisról és a szolgáltatóról. Ez a persistence.xml fájlban történik, amint az a 10.felsorolásban látható.
10. Kitartás.xml
vannak más módon, hogy ezt az információt, hogy a rendszer, beleértve a programozottan. Javaslom a persistence.xml fájl használatát, mivel a függőségek ilyen módon történő tárolása nagyon egyszerűvé teszi az alkalmazás frissítését kód módosítása nélkül.
tavaszi konfiguráció JPA
a tavasz használata nagyban megkönnyíti a JPA integrációját az alkalmazásba. Például a @SpringBootApplication annotáció elhelyezése az alkalmazás fejlécében arra utasítja a Spring-t, hogy automatikusan vizsgálja meg az osztályokat, és adja be a EntityManager – ot, szükség szerint a megadott konfiguráció alapján.
Listing 11 mutatja a függőségek közé, ha azt szeretné, Spring JPA támogatást az alkalmazás.
lista 11. Tavaszi JPA támogatás hozzáadása a Maven
következtetés
minden adatbázissal foglalkozó alkalmazásnak meg kell határoznia egy olyan alkalmazási réteget, amelynek egyetlen célja a perzisztencia kód elkülönítése. Amint azt ebben a cikkben láthattuk, a Java Persistence API számos lehetőséget és támogatást nyújt a Java objektum perzisztencia számára. Az egyszerű alkalmazások nem feltétlenül igénylik a JPA összes képességét, egyes esetekben a keretrendszer konfigurálásának felső értéke nem feltétlenül előnyös. Ahogy azonban egy alkalmazás növekszik, a JPA szerkezete és kapszulázása valóban kiérdemelte a megtartását. A JPA használata egyszerűvé teszi az objektumkódot, és hagyományos keretet biztosít az adatokhoz való hozzáféréshez Java alkalmazásokban.
Tudjon meg többet a Java Persistence API-ról és a kapcsolódó technológiákról
- mi az a JDBC? Bevezetés a Java adatbázis-kapcsolatba: Ismerje meg a Java alacsony szintű API-ját az adatbázishoz való csatlakozáshoz, SQL lekérdezések kiadásához stb.
- Java persistence with JPA and Hibernate, Part 1: entitások and relationships: Get started modeling entities and relationships with Java 8 and Hibernate ORM.
- Java persistence with JPA and Hibernate, Part 2: Gyakorlati gyakorlat modellezés sok-sok Kapcsolatok és öröklési kapcsolatok Java 8 és Hibernate ORM.
- állapotfüggő viselkedés végrehajtása: klasszikus Bevezetés Az Állapotmintába és az állapotfüggőségbe Java-ban.
- lelkes / lusta Betöltés hibernált állapotban: hogyan kell alkalmazni a lelkes és lusta betöltést hibernált állapotban.
- a JPA 2.2 néhány nagyon várt változást hoz: a JPA 2.2 specifikációfrissítéseinek áttekintése, beleértve a CDI javítását, a dátum és idő API jobb összehangolását, valamint a
@Repeatableannotációk támogatását. - ha a JPA-t használja a következő projekthez?: Kulcsfontosságú kérdések, amelyek segíthetnek dönteni.