Programmering

Hva er JPA? Introduksjon til Java Persistence API

Som en spesifikasjon er Java Persistence API opptatt av standhaftighet, som løst betyr enhver mekanisme der Java-objekter overlever applikasjonsprosessen som opprettet dem. Ikke alle Java-objekter trenger å være vedvarende, men de fleste applikasjoner vedvarer viktige forretningsobjekter. JPA-spesifikasjonen lar deg definere hvilken gjenstander skal være vedvarende, og hvordan disse objektene skal vedvares i Java-applikasjonene dine.

I seg selv er ikke JPA et verktøy eller rammeverk; snarere definerer det et sett med konsepter som kan implementeres av ethvert verktøy eller rammeverk. Mens JPAs modell-relasjonelle kartlegging (ORM) -modellen opprinnelig var basert på dvalemodus, har den siden utviklet seg. På samme måte, mens JPA opprinnelig var ment for bruk med relasjons- / SQL-databaser, har noen JPA-implementeringer blitt utvidet for bruk med NoSQL-datalagre. Et populært rammeverk som støtter JPA med NoSQL er EclipseLink, referanseimplementeringen for JPA 2.2.

JPA 2.2 i Jakarta EE

Java Persistence API ble først utgitt som en delmengde av EJB 3.0-spesifikasjonen (JSR 220) i Java EE 5. Den har siden utviklet seg som sin egen spesifikasjon, og startet med utgivelsen av JPA 2.0 i Java EE 6 (JSR 317). I skrivende stund er JPA 2.2 vedtatt for videreføring som en del av Jakarta EE.

JPA og dvalemodus

På grunn av deres sammenflettede historie blir dvalemodus og JPA ofte sammenflettet. I likhet med Java Servlet-spesifikasjonen har JPA imidlertid skapt mange kompatible verktøy og rammer; Dvalemodus er bare en av dem.

Hibernate er utviklet av Gavin King og utgitt tidlig i 2002, og er et ORM-bibliotek for Java. King utviklet Hibernate som et alternativ til enhetsbønner for utholdenhet. Rammeverket var så populært, og så nødvendig på den tiden, at mange av ideene ble vedtatt og kodifisert i den første JPA-spesifikasjonen.

I dag er dvalemodus ORM en av de mest modne JPA-implementeringene, og fortsatt et populært alternativ for ORM i Java. Dvalemodus ORM 5.3.8 (den nåværende versjonen fra og med dette skrivet) implementerer JPA 2.2. I tillegg har Hibernates familie av verktøy blitt utvidet til å omfatte populære verktøy som Hibernate Search, Hibernate Validator og Hibernate OGM, som støtter vedvarende domenemodell for NoSQL.

JPA og EJB

Som nevnt tidligere ble JPA introdusert som en delmengde av EJB 3.0, men har siden utviklet seg som sin egen spesifikasjon. EJB er en spesifikasjon med et annet fokus enn JPA, og er implementert i en EJB-container. Hver EJB-container inneholder et utholdenhetslag, som er definert av JPA-spesifikasjonen.

Hva er Java ORM?

Mens de er forskjellige i utførelse, gir hver JPA-implementering noen form for ORM-lag. For å forstå JPA og JPA-kompatible verktøy, må du ha god forståelse av ORM.

Objektrelasjonell kartlegging er en oppgave–En som utviklere har god grunn til å unngå å gjøre manuelt. Et rammeverk som Hibernate ORM eller EclipseLink kodifiserer den oppgaven i et bibliotek eller rammeverk, et ORM-lag. Som en del av applikasjonsarkitekturen er ORM-laget ansvarlig for å administrere konverteringen av programvareobjekter for å samhandle med tabellene og kolonnene i en relasjonsdatabase. I Java konverterer ORM-laget Java-klasser og objekter slik at de kan lagres og administreres i en relasjonsdatabase.

Som standard blir navnet på objektet som vedvares navnet på tabellen, og felt blir kolonner. Når tabellen er satt opp, tilsvarer hver tabellrad et objekt i applikasjonen. Objektkartlegging kan konfigureres, men standardene har en tendens til å fungere bra.

JPA med NoSQL

Inntil ganske nylig var ikke-relasjonelle databaser uvanlige kuriositeter. NoSQL-bevegelsen endret alt det, og nå er en rekke NoSQL-databaser tilgjengelig for Java-utviklere. Noen JPA-implementeringer har utviklet seg til å omfavne NoSQL, inkludert Hibernate OGM og EclipseLink.

Figur 1 illustrerer rollen til JPA og ORM-laget i applikasjonsutvikling.

JavaWorld /

Konfigurere Java ORM-laget

Når du setter opp et nytt prosjekt for å bruke JPA, må du konfigurere datalageret og JPA-leverandøren. Du konfigurerer en datalagerkontakt for å koble til den valgte databasen (SQL eller NoSQL). Du vil også inkludere og konfigurere JPA-leverandør, som er et rammeverk som Hibernate eller EclipseLink. Mens du kan konfigurere JPA manuelt, velger mange utviklere å bruke Spring's out-of-the-box-støtte. Se "JPA installasjon og oppsett"nedenfor for en demonstrasjon av både manuell og vårbasert JPA installasjon og oppsett.

Java Data Objects

Java Data Objects er et standardisert utholdenhetsrammeverk som skiller seg fra JPA primært ved å støtte utholdenhetslogikk i objektet, og ved sin mangeårige støtte for å jobbe med ikke-relasjonelle datalagre. JPA og JDO er like nok til at JDO-leverandører ofte også støtter JPA. Se Apache JDO Project for å lære mer om JDO i forhold til andre utholdenhetsstandarder som JPA og JDBC.

Datapresistens i Java

Fra et programmeringsperspektiv er ORM-laget et adapterlag: det tilpasser språket til objektgrafer til språket i SQL og relasjonstabeller. ORM-laget lar objektorienterte utviklere bygge programvare som vedvarer data uten å forlate det objektorienterte paradigmet.

Når du bruker JPA, oppretter du en kart fra datalageret til programmets datamodellobjekter. I stedet for å definere hvordan objekter lagres og hentes, definerer du kartleggingen mellom objekter og databasen din, og påkaller deretter JPA for å vedvare dem. Hvis du bruker en relasjonsdatabase, vil mye av den faktiske forbindelsen mellom applikasjonskoden og databasen bli håndtert av JDBC, Java Database Connectivity API.

Som spesifikasjon gir JPA merknader om metadata, som du bruker til å definere kartleggingen mellom objekter og databasen. Hver JPA-implementering gir sin egen motor for JPA-merknader. JPA-spesifikasjonen gir også PersistanceManager eller EntityManager, som er de viktigste kontaktpunktene med JPA-systemet (hvor din forretningslogikkode forteller systemet hva de skal gjøre med de tilordnede objektene).

For å gjøre alt dette mer konkret, bør du vurdere Listing 1, som er en enkel dataklasse for modellering av en musiker.

Oppføring 1. En enkel dataklasse i Java

 offentlig klasse Musiker {privat Lang id; privat strengnavn; private Instrument mainInstrument; private ArrayList forestillinger = nye ArrayList (); offentlig musiker (lang id, strengnavn) {/ * konstruktorsettere ... * /} offentlig ugyldig settnavn (strengnavn) {dette.navn = navn; } public String getName () {return this.name; } public void setMainInstrument (Instrument instr) {this.instrument = instr; } offentlig Instrument getMainInstrument () {returner this.instrument; } // ... Andre getters og setters ...} 

De Musiker klasse i Listing 1 brukes til å lagre data. Den kan inneholde primitive data som Navn felt. Det kan også holde forhold til andre klasser som mainInstrument og forestillinger.

Musikers grunn til å være skal inneholde data. Denne typen klasser er noen ganger kjent som en DTO, eller dataoverføringsobjekt. DTO-er er et vanlig trekk ved programvareutvikling. Mens de har mange slags data, inneholder de ingen forretningslogikk. Vedvarende dataobjekter er en allestedsnærværende utfordring i programvareutvikling.

Datapresistens med JDBC

En måte å lagre en forekomst av Musiker klasse til en relasjonsdatabase ville være å bruke JDBC-biblioteket. JDBC er et abstraksjonslag som lar et program utstede SQL-kommandoer uten å tenke på den underliggende databaseimplementeringen.

Oppføring 2 viser hvordan du kan vedvare Musiker klasse ved hjelp av JDBC.

Oppføring 2. JDBC setter inn en plate

 Musiker georgeHarrison = ny musiker (0, "George Harrison"); String myDriver = "org.gjt.mm.mysql.Driver"; String myUrl = "jdbc: mysql: // localhost / test"; Class.forName (myDriver); Connection conn = DriverManager.getConnection (myUrl, "root", ""); Strengspørsmål = "sett inn i brukere (id, navn) verdier (?,?)"; PreparedStatement preparedStmt = conn.prepareStatement (spørring); preparedStmt.setInt (1, 0); preparedStmt.setString (2, "George Harrison"); preparedStmt.setString (2, "Rubble"); preparedStmt.execute (); conn.close (); // Feilhåndtering fjernet for kortfattethet 

Koden i Listing 2 er ganske selvdokumenterende. De georgeHarrison objektet kan komme hvor som helst (frontend-send, ekstern tjeneste osv.), og har ID- og navnefelt angitt. Feltene på objektet blir deretter brukt til å levere verdiene til en SQL sett inn uttalelse. (De PreparedStatement klasse er en del av JDBC, og tilbyr en måte å trygt bruke verdier på en SQL-spørring.)

Mens JDBC tillater kontrollen som kommer med manuell konfigurasjon, er det tungvint i forhold til JPA. For å endre databasen, må du først opprette et SQL-spørsmål som tilordnes fra Java-objektet til tabellene i en relasjonsdatabase. Du må da endre SQL når en objektsignatur endres. Med JDBC blir vedlikehold av SQL en oppgave i seg selv.

Datapersistens med JPA

Vurder nå Listing 3, hvor vi vedvarer Musiker klasse ved hjelp av JPA.

Oppføring 3. Vedvare George Harrison med JPA

 Musiker georgeHarrison = ny musiker (0, "George Harrison"); musicianManager.save (georgeHarrison); 

Listing 3 erstatter den manuelle SQL fra Listing 2 med en enkelt linje, session.save (), som instruerer JPA om å vedvare objektet. Fra da av blir SQL-konverteringen håndtert av rammeverket, slik at du aldri trenger å forlate det objektorienterte paradigmet.

Merknader om metadata i JPA

Magien i Listing 3 er resultatet av en konfigurasjon, som er opprettet ved hjelp av JPAs merknader. Utviklere bruker merknader for å informere JPA om hvilke objekter som skal vedvares, og hvordan de skal vedholdes.

Oppføring 4 viser Musiker klasse med en enkelt JPA-kommentar.

Oppføring 4. JPAs @Entity-kommentar

 @Entity offentlig klasse musiker {// ..klassekropp} 

Vedvarende gjenstander kalles noen ganger enheter. Festing @Enhet til en klasse som Musiker informerer JPA om at denne klassen og dens objekter skal være vedvarende.

XML vs. kommentarbasert konfigurasjon

JPA støtter også bruk av eksterne XML-filer, i stedet for merknader, for å definere klassemetadata. Men hvorfor skulle du gjøre det mot deg selv?

Konfigurere JPA

Som de fleste moderne rammer, omfavner JPA koding etter konvensjon (også kjent som konvensjon over konfigurasjon), der rammeverket gir en standardkonfigurasjon basert på bransjens beste praksis. Som et eksempel, en klasse som heter Musiker vil bli kartlagt som standard til en databasetabell som heter Musiker.

Den konvensjonelle konfigurasjonen er tidsbesparende, og i mange tilfeller fungerer den bra nok. Det er også mulig å tilpasse JPA-konfigurasjonen. Som et eksempel kan du bruke JPA-er @Bord kommentar for å spesifisere tabellen der Musiker klasse skal lagres.

Oppføring 5. JPAs @Table-kommentar

 @Entity @Table (name = "musiker") offentlig klasse musiker {// ..klassekropp} 

Oppføring 5 forteller JPA å vedvare enheten (Musiker klasse) til musiker bord.

Primærnøkkel

I JPA er den primærnøkkel er feltet som brukes til å identifisere hvert objekt i databasen på en unik måte. Primærnøkkelen er nyttig for å referere til og relatere objekter til andre enheter. Når du lagrer et objekt i en tabell, vil du også spesifisere feltet som skal brukes som primærnøkkel.

I oppføring 6 forteller vi JPA hvilket felt vi skal bruke som Musikerprimærnøkkel.

Oppføring 6. Spesifisering av primærnøkkel

 @Entity offentlig klasse musiker {@Id privat Lang id; 

I dette tilfellet har vi brukt JPA-er @Id kommentar for å spesifisere id felt som Musikerprimærnøkkel. Som standard antar denne konfigurasjonen at den primære nøkkelen blir satt av databasen - for eksempel når feltet er satt til automatisk økning på bordet.

JPA støtter andre strategier for å generere et objekts hovednøkkel. Den har også merknader for å endre individuelle feltnavn. Generelt er JPA fleksibel nok til å tilpasse seg utholdenhetskartleggingen du måtte trenge.

CRUD-operasjoner

Når du har kartlagt en klasse til en databasetabell og etablert den primære nøkkelen, har du alt du trenger for å opprette, hente, slette og oppdatere den klassen i databasen. Ringer session.save () vil opprette eller oppdatere den angitte klassen, avhengig av om primærnøkkelfeltet er null eller gjelder en eksisterende enhet. Ringer entityManager.remove () vil slette den angitte klassen.

Enhetsrelasjoner i JPA

Bare å vedvare et objekt med et primitivt felt er bare halve ligningen. JPA har også muligheten til å administrere enheter i forhold til hverandre. Fire typer enhetsforhold er mulig i både tabeller og objekter:

    1. En-til-mange
    2. Mange-til-en
    3. Mange-til-mange
    4. En-til-en

Hver type forhold beskriver hvordan en enhet forholder seg til andre enheter. For eksempel Musiker enhet kan ha en en-til-mange-forhold med Opptreden, en enhet representert av en samling som Liste eller Sett.

Hvis den Musiker inkludert a Bånd felt, kan forholdet mellom disse enhetene være mange-mot-en, antyder samling av Musikers på singelen Bånd klasse. (Forutsatt at hver musiker bare opptrer i et enkelt band.)

Hvis Musiker inkludert a BandMates felt, som kan representere et mange-til-mange forhold med andre Musiker enheter.

Endelig, Musiker kan ha en en-til-en-forhold med en Sitat enhet, brukes til å representere et kjent sitat: Sitat famousQuote = nytt tilbud ().

Definere relasjonstyper

JPA har merknader for hver av forholdstypene for forholdskartlegging. Oppføring 7 viser hvordan du kan kommentere forholdet mellom mange Musiker og Opptredens.

Oppføring 7. Annotering av en-til-mange forhold

$config[zx-auto] not found$config[zx-overlay] not found