streamalism.org

1. Oversigt

I denne hurtige artikel vil vi fokusere på forskellige slags Spring Data repository-grænseflader og deres funktionalitet. Vi berører:

• CrudRepository
• PagingAndSortingRepository
• JpaRepository

Kort sagt, hvert lager i Spring Data udvider det generiske Datalager interface, men ud over det har de hver sin funktionalitet.

2. Spring Data Repositories

Lad os starte med JpaRepository - som strækker sig PagingAndSortingRepository og til gengæld CrudRepository.

Hver af disse definerer sin egen funktionalitet:

• CrudRepository giver CRUD-funktioner
• PagingAndSortingRepository giver metoder til at udføre paginering og sortere poster
• JpaRepository giver JPA-relaterede metoder såsom at skylle persistens-konteksten og slette poster i en batch

Og så på grund af dette arveforhold, JpaRepository indeholder den fulde API af CrudRepository og PagingAndSortingRepository.

Når vi ikke har brug for den fulde funktionalitet, der leveres af JpaRepository og PagingAndSortingRepository, vi kan simpelthen bruge CrudRepository.

Lad os nu se på et hurtigt eksempel for at forstå disse API'er bedre.

Vi starter med et simpelt Produkt enhed:

@Entity offentlig klasse produkt {@Id privat langt id; privat strengnavn; // getters og setters}

Og lad os implementere en simpel operation - find en Produkt baseret på dets navn:

@Repository offentlig grænseflade ProductRepository udvider JpaRepository {Product findByName (String productName); }

Det er alt. Spring Data Repository genererer automatisk implementeringen baseret på det navn, vi har givet det.

Dette var selvfølgelig et meget simpelt eksempel; Du kan gå dybere ind i Spring Data JPA her.

3. CrudRepository

Lad os nu se på koden til CrudRepository grænseflade:

offentlig grænseflade CrudRepository udvider lager {S gem (S enhed); T findOne (ID-primærnøgle); Iterabel findAll (); Lang optælling (); ugyldig sletning (T-enhed); boolsk eksisterer (ID primær nøgle); }

Bemærk den typiske CRUD-funktionalitet:

• gem (...) - save en Iterabel af enheder. Her kan vi videregive flere objekter for at gemme dem i en batch
• findOne (…) - få en enkelt enhed baseret på bestået primærnøgleværdi
• findAll () - få en Iterabel af alle tilgængelige enheder i databasen
• tælle () - returnere antallet af samlede enheder i en tabel
• slet (...) - slet en enhed baseret på det passerede objekt
• eksisterer (…) - kontroller, om der findes en enhed baseret på den beståede primære nøgleværdi

Denne grænseflade ser ret generisk og enkel ud, men faktisk giver den alle grundlæggende forespørgselsabstraktioner, der er nødvendige i en applikation.

4. PagingAndSortingRepository

Lad os nu se på en anden lagergrænseflade, der strækker sig CrudRepository:

offentlig grænseflade PagingAndSortingRepository udvider CrudRepository {Iterable findAll (Sort sort); Side findAll (Sider, der kan sides) }

Denne grænseflade giver en metode findAll (Pageable pageable), som er nøglen til implementering Paginering.

Ved brug Sidelig, opretter vi en Sidelig objekt med visse egenskaber, og vi skal mindst angive:

1. Sidestørrelse
2. Aktuelt sidetal
3. Sortering

Så lad os antage, at vi vil vise den første side i et resultatsæt sorteret efter efternavn, stigende med højst fem poster hver. Sådan kan vi opnå dette ved hjælp af en PageRequest og en Sortere definition:

Sort sort = new Sort (ny Sort.Order (Retning.ASC, "efternavn")); Pageable pageable = new PageRequest (0, 5, sort);

At sende det sidelige objekt til Spring-dataforespørgslen returnerer de pågældende resultater (den første parameter i PageRequest er nulbaseret).

5. JpaRepository

Endelig skal vi se på JpaRepository grænseflade:

offentlig grænseflade JpaRepository udvider PagingAndSortingRepository {List findAll (); Liste findAll (Sort sort); Liste gemme (Iterable enheder); ugyldig flush (); T saveAndFlush (T-enhed); ugyldig deleteInBatch (Iterable enheder); }

Lad os igen kort se på hver af disse metoder:

• findAll () - få en Liste af alle tilgængelige enheder i databasen
• findAll (...) - få en Liste af alle tilgængelige enheder, og sorter dem efter den angivne betingelse
• gem (...) - save en Iterabel af enheder. Her kan vi videregive flere objekter for at gemme dem i en batch
• skylle () - ffrodige alle afventende opgaver til databasen
• saveAndFlush (…) - gem enheden og skyl ændringer straks
• deleteInBatch (…) - slet en Iterabel af enheder. Her kan vi videregive flere objekter for at slette dem i en batch

Det er klart, at ovenstående interface udvides PagingAndSortingRepository hvilket betyder, at den har alle metoder til stede i CrudRepository såvel.

6. Ulemper ved Spring Data Repositories

Ud over alle de meget nyttige fordele ved disse arkiver er der nogle grundlæggende ulemper ved direkte afhængigt af disse også:

1. vi kobler vores kode til biblioteket og dets specifikke abstraktioner, såsom 'Side' eller 'Siderbar'; det er naturligvis ikke unikt for dette bibliotek - men vi skal være forsigtige med ikke at udsætte disse interne implementeringsoplysninger
2. ved at udvide f.eks. CrudRepository, vi udsætter et komplet sæt persistensmetode på én gang. Dette er sandsynligvis fint under de fleste omstændigheder, men vi kan løbe ind i situationer, hvor vi gerne vil have mere finkornet kontrol over de eksponerede metoder, f.eks. at oprette en ReadOnlyRepository der inkluderer ikke Gemme(…) og slet (...) metoder til CrudRepository

7. Konklusion

Denne artikel dækkede nogle korte, men vigtige forskelle og funktioner i Spring Data JPA repository-grænseflader.

For mere information, se på serien om Spring Persistence.