streamalism.org

1. Oversikt

I denne raske artikkelen vil vi fokusere på ulike typer Spring Data repository-grensesnitt og deres funksjonalitet. Vi berører:

• CrudRepository
• PagingAndSortingRepository
• JpaRepository

Enkelt sagt, hvert lager i Spring Data utvider det generiske Oppbevaringssted grensesnitt, men utover det har de hver sin forskjellige funksjonalitet.

2. Spring Data Repositories

La oss starte med JpaRepository - som strekker seg PagingAndSortingRepository og i sin tur den CrudRepository.

Hver av disse definerer sin egen funksjonalitet:

• CrudRepository gir CRUD-funksjoner
• PagingAndSortingRepository gir metoder for å gjøre paginering og sortere poster
• JpaRepository gir JPA-relaterte metoder som å skylle utholdenhetskonteksten og slette poster i en batch

Og så, på grunn av dette arveforholdet, har JpaRepository inneholder hele API av CrudRepository og PagingAndSortingRepository.

Når vi ikke trenger den fulle funksjonaliteten som tilbys av JpaRepository og PagingAndSortingRepository, kan vi ganske enkelt bruke CrudRepository.

La oss nå se på et raskt eksempel for å forstå disse API-ene bedre.

Vi begynner med en enkel Produkt enhet:

@Entity offentlig klasse Produkt {@Id privat lang id; privat strengnavn; // getters og setters}

Og la oss implementere en enkel operasjon - finn en Produkt basert på navnet:

@Repository offentlig grensesnitt ProductRepository utvider JpaRepository {Product findByName (String productName); }

Det er alt. Spring Data Repository vil automatisk generere implementeringen basert på navnet vi ga den.

Dette var selvfølgelig et veldig enkelt eksempel; du kan gå dypere inn i Spring Data JPA her.

3. CrudRepository

La oss nå ta en titt på koden for CrudRepository grensesnitt:

offentlig grensesnitt CrudRepository utvider Repository {S save (S entity); T findOne (ID primærnøkkel); Iterable findAll (); Langtelling (); ugyldig sletting (T-enhet); boolsk eksisterer (ID primærnøkkel); }

Legg merke til den typiske CRUD-funksjonaliteten:

• lagre (…) - save an Iterabel av enheter. Her kan vi sende flere objekter for å lagre dem i en batch
• Finn én(…) - få en enhet basert på bestått primærnøkkelverdi
• findAll () - få en Iterabel av alle tilgjengelige enheter i databasen
• telle () - return antall antall enheter i en tabell
• slett (...) - slett en enhet basert på det passerte objektet
• eksisterer (…) - bekreft om en enhet eksisterer basert på den passerte primærnøkkelverdien

Dette grensesnittet ser ganske generisk og enkelt ut, men faktisk gir det alle grunnleggende spørreabstraksjoner som trengs i et program.

4. PagingAndSortingRepository

La oss nå se på et annet depotgrensesnitt som strekker seg CrudRepository:

offentlig grensesnitt PagingAndSortingRepository utvider CrudRepository {Iterable findAll (Sort sort); Side findAll (Sidesidig side); }

Dette grensesnittet gir en metode findAll (Pageable pageable), som er nøkkelen til implementering Paginering.

Når du bruker Sidelig, lager vi en Sidelig objekt med visse egenskaper, og vi må spesifisere minst:

1. Sidestørrelse
2. Gjeldende sidenummer
3. Sortering

La oss anta at vi vil vise den første siden i et resultatsett sortert etter etternavn, stigende, og har ikke mer enn fem poster hver. Slik kan vi oppnå dette ved hjelp av a PageRequest og en Sortere definisjon:

Sort sort = new Sort (new Sort.Order (Direction.ASC, "lastName")); Sidesidet siden = ny PageRequest (0, 5, sorter);

Hvis du sender det sideholdbare objektet til vårdata-spørringen, returneres de aktuelle resultatene (den første parameteren for PageRequest er nullbasert).

5. JpaRepository

Til slutt vil vi ta en titt på JpaRepository grensesnitt:

offentlig grensesnitt JpaRepository utvider PagingAndSortingRepository {List findAll (); Liste findAll (Sort sort); Liste lagre (Iterable enheter); void flush (); T saveAndFlush (T-enhet); ugyldig deleteInBatch (Iterable enheter); }

Igjen, la oss se på hver av disse metodene i korte trekk:

• findAll () - få en Liste av alle tilgjengelige enheter i databasen
• findAll (...) - få en Liste av alle tilgjengelige enheter, og sorter dem etter den angitte tilstanden
• lagre (…) - save an Iterabel av enheter. Her kan vi sende flere objekter for å lagre dem i en batch
• flush () - ffrodig all ventende oppgave til databasen
• saveAndFlush (…) - lagre enheten og spyl endringene umiddelbart
• deleteInBatch (…) - slett en Iterabel av enheter. Her kan vi sende flere objekter for å slette dem i en batch

Det er klart at grensesnittet utvides PagingAndSortingRepository som betyr at den har alle metodene tilstede i CrudRepository også.

6. Ulemper ved Spring Data Repositories

Utover alle de veldig nyttige fordelene med disse depotene, er det noen grunnleggende ulemper ved direkte avhengig av disse også:

1. vi kobler koden vår til biblioteket og til dens spesifikke abstraksjoner, for eksempel `Page` eller` Pageable`; det er selvfølgelig ikke unikt for dette biblioteket - men vi må være forsiktige med å ikke avsløre disse interne implementeringsdetaljene
2. ved å utvide f.eks. CrudRepository, avslører vi et komplett sett med utholdenhetsmetode på en gang. Dette er sannsynligvis greit i de fleste tilfeller også, men vi kan komme i situasjoner der vi ønsker å få mer finkornet kontroll over de eksponerte metodene, f.eks. å lage en ReadOnlyRepository som ikke inkluderer lagre(…) og slett (...) metoder for CrudRepository

7. Konklusjon

Denne artikkelen dekket noen korte, men viktige forskjeller og funksjoner i Spring Data JPA repository-grensesnitt.

For mer informasjon, ta en titt på serien Spring Persistence.