Introduksjon til Spring Data JPA

1. Oversikt

Denne artikkelen vil fokusere på introdusere Spring Data JPA i et Spring-prosjekt og fullstendig konfigurere utholdenhetslaget. For en trinnvis introduksjon om å sette opp vårkonteksten ved hjelp av Java-basert konfigurasjon og den grunnleggende Maven pom for prosjektet, se denne artikkelen.

2. Vårdata genererte DAO - Ingen flere DAO-implementeringer

Som vi diskuterte i en tidligere artikkel, består DAO-laget vanligvis av mye kjelekode som kan og bør forenkles. Fordelene med en slik forenkling er mange: en reduksjon i antall gjenstander som vi trenger å definere og vedlikeholde, konsistensen av datatilgangsmønstre og konsistensen av konfigurasjonen.

Spring Data tar denne forenklingen ett skritt fremover og gjør det mulig å fjerne DAO-implementeringene helt. Grensesnittet til DAO er nå den eneste gjenstanden som vi trenger å definere eksplisitt.

For å begynne å utnytte Spring Data-programmeringsmodellen med JPA, må et DAO-grensesnitt utvide JPA-spesifikk Oppbevaringssted grensesnitt - JpaRepository. Dette vil gjøre det mulig for Spring Data å finne dette grensesnittet og automatisk opprette en implementering for det.

Ved å utvide grensesnittet får vi de mest relevante CRUD-metodene for standard datatilgang tilgjengelig i en standard DAO.

3. Tilpasset tilgangsmetode og spørsmål

Som diskutert, ved å implementere en av Oppbevaringssted grensesnitt, vil DAO allerede ha noen grunnleggende CRUD-metoder (og spørsmål) definert og implementert.

For å definere mer spesifikke tilgangsmetoder støtter Spring JPA ganske mange alternativer:

  • ganske enkelt definere en ny metode i grensesnittet
  • gi den faktiske JPQL-spørring ved å bruke @Spørsmål kommentar
  • bruk de mer avanserte Spesifikasjon og Querydsl-støtte i vårdata
  • definere tilpassede spørsmål via JPA Named Queries

Det tredje alternativet - Spesifikasjoner og Querydsl-støtte - ligner på JPA-kriterier, men bruker en mer fleksibel og praktisk API. Dette gjør hele operasjonen mye mer lesbar og gjenbrukbar. Fordelene med denne API-en vil bli mer uttalt når vi arbeider med et stort antall faste spørsmål, da vi potensielt kan uttrykke disse mer kortfattet gjennom et mindre antall gjenbrukbare blokker.

Dette siste alternativet har den ulempen at det enten involverer XML eller tynger domeneklassen med spørsmålene.

3.1. Automatiske tilpassede spørsmål

Når Spring Data oppretter en ny Oppbevaringssted implementering, analyserer den alle metodene som er definert av grensesnittene og prøver å genererer automatisk spørsmål fra metodenavnene. Selv om dette har noen begrensninger, er det en veldig kraftig og elegant måte å definere nye tilpassede tilgangsmetoder med veldig liten innsats.

La oss se på et eksempel: hvis enheten har en Navn felt (og Java Bean-standarden getName og setName metoder), vi definerer findByName metode i DAO-grensesnittet; dette genererer automatisk riktig spørring:

offentlig grensesnitt IFooDAO utvider JpaRepository {Foo findByName (strengnavn); }

Dette er et relativt enkelt eksempel. Søkeopprettelsesmekanismen støtter et mye større sett med nøkkelord.

I tilfelle at parseren ikke kan matche egenskapen med feltet domeneobjekt, ser vi følgende unntak:

java.lang.IllegalArgumentException: Ingen eiendomsnavn funnet for type class com.baeldung.spring.data.persistence.model.Foo

3.2. Manuelle tilpassede spørsmål

La oss nå se på et tilpasset spørsmål som vi definerer via @Spørsmål kommentar:

@Query ("SELECT f FROM Foo f WHERE LOWER (f.name) = LOWER (: name)") Foo retrieveByName (@Param ("name") Strengnavn);

For enda mer detaljert kontroll over opprettelsen av spørringer, for eksempel ved å bruke navngitte parametere eller endre eksisterende spørringer, er referansen et godt sted å starte.

4. Transaksjonskonfigurasjon

Den faktiske implementeringen av den vårstyrte DAO er faktisk skjult siden vi ikke jobber med den direkte. Dette er imidlertid en enkel nok implementering - de SimpleJpaRepository - som definerer transaksjonssemantikk ved hjelp av merknader.

Mer eksplisitt bruker dette en skrivebeskyttet @Transaksjonell kommentar på klassenivå, som deretter overstyres for ikke-skrivebeskyttede metoder. Resten av transaksjonssemantikken er standard, men disse kan lett overstyres manuelt per metode.

4.1. Unntaksoversettelse er levende og vel

Spørsmålet er nå - siden Spring Data JPA ikke er avhengig av de gamle ORM-malene (JpaTemplate, Dvalemodus) og de er fjernet siden vår 5 - skal vi fortsatt få våre JPA-unntak oversatt til vårens DataAccessException hierarki?

Selvfølgelig er vi - unntaksoversettelse er fremdeles aktivert ved bruk av @Oppbevaringssted kommentar på DAO. Denne kommentaren gjør det mulig for en postbearbeider av vårbønne å gi råd til alle @Oppbevaringssted bønner med alle PersistenceExceptionTranslator forekomster funnet i containeren, og gir unntaksoversettelse som før.

La oss verifisere oversettelse av unntak med en integrasjonstest:

@Test (forventet = DataIntegrityViolationException.class) offentlig ugyldig givenFooHasNoName_whenInvalidEntityIsCreated_thenDataException () {service.create (new Foo ()); }

Husk det unntak oversettelse gjøres gjennom fullmakter. For at våren skal kunne lage fullmakter rundt DAO-klassene, må disse ikke erklæres endelig.

5. Spring Data JPA Repository Configuration

For å aktivere Spring JPA repository support kan vi bruke @EnableJpaRepositories kommentar og spesifiser pakken som inneholder DAO-grensesnittene:

@EnableJpaRepositories (basePackages = "com.baeldung.spring.data.persistence.repository") offentlig klasse PersistenceConfig {...}

Vi kan gjøre det samme med en XML-konfigurasjon:

6. Java- eller XML-konfigurasjon

Vi har allerede diskutert i detalj hvordan du konfigurerer JPA om våren i en forrige artikkel. Spring Data benytter seg også av Springs støtte til JPA @PersistenceContext kommentar. Den bruker dette til å koble til EntityManager inn i vårfabrikken som er ansvarlig for å lage de faktiske DAO-implementeringene - JpaRepositoryFactoryBean.

I tillegg til den allerede diskuterte konfigurasjonen, må vi også inkludere Spring Data XML Config - hvis vi bruker XML:

@Configuration @EnableTransactionManagement @ImportResource ("classpath *: * springDataConfig.xml") offentlig klasse PersistenceJPAConfig {...}

7. Maven avhengighet

I tillegg til Maven-konfigurasjonen for JPA, som i en forrige artikkel, legger vi til vår-data-jpa avhengighet:

 org.springframework.data spring-data-jpa 2.2.7.RELEASE 

8. Bruke vårstøvel

Vi kan også bruke Spring Boot Starter Data JPA-avhengighet som automatisk konfigurerer Datakilde for oss.

Vi må også sørge for at databasen vi vil bruke, er til stede i klassestien. I vårt eksempel har vi lagt til H2-minnedatabasen:

 org.springframework.boot spring-boot-starter-data-jpa 2.2.6.RELEASE com.h2database h2 1.4.200 

Som et resultat, bare ved å gjøre disse avhengighetene, er applikasjonen vår i gang, og vi kan bruke den til andre databaser.

Den eksplisitte konfigurasjonen for en standard Spring-applikasjon er nå inkludert som en del av Spring Boot auto-konfigurasjon.

Vi kan selvfølgelig endre den automatiske konfigurasjonen ved å legge til vår tilpassede eksplisitte konfigurasjon.

Spring Boot gir en enkel måte å gjøre dette ved hjelp av egenskaper i application.properties fil:

spring.datasource.url = jdbc: h2: mem: db; DB_CLOSE_DELAY = -1 spring.datasource.username = sa spring.datasource.password = sa

I dette eksemplet har vi endret tilkoblings-URL og legitimasjon.

9. Konklusjon

Denne artikkelen dekket konfigurasjonen og implementeringen av utholdenhetslaget med Spring 5, JPA 2 og Spring Data JPA (en del av Spring Data-paraplyprosjektet), ved bruk av både XML- og Java-basert konfigurasjon.

Vi diskuterte måter å definere mer på avanserte tilpassede spørsmål, i tillegg til transaksjonell semantikk, og en konfigurasjon med det nye jpa navneområdet. Det endelige resultatet er en ny og elegant tilgang til datatilgang med Spring, nesten ikke noe faktisk implementeringsarbeid.

Implementeringen av denne vårdata-JPA-veiledningen finner du i GitHub-prosjektet.


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