streamalism.org

1. Oversikt

Apache DeltaSpike er et prosjekt som gir en samling av CDI-utvidelser for Java-prosjekter; det krever at en CDI-implementering er tilgjengelig på kjøretid.

Selvfølgelig kan det fungere med den forskjellige implementeringen av CDI - JBoss Weld eller OpenWebBeans. Den er også testet på mange applikasjonsservere.

I denne opplæringen vil vi fokusere på en av de mest kjente og nyttige - datamodulen.

2. DeltaSpike datamoduloppsett

Apache DeltaSpike Data-modulen er vant til forenkle implementeringen av depotmønsteret. Det tillater redusere en kjelekode ved å gi sentralisert logikk for oppretting og utføring av spørsmål.

Det ligner veldig på Spring Data-prosjektet. For å spørre om en database må vi definere en metodedeklarasjon (uten implementering) som følger definert navnekonvensjon eller som inneholder @Spørsmål kommentar. Implementeringen vil bli gjort for oss av CDI-utvidelsen.

I de neste underavsnittene vil vi dekke hvordan du konfigurerer Apache DeltaSpike Data-modulen i applikasjonen vår.

2.1. Nødvendige avhengigheter

For å bruke Apache DeltaSpike Data-modulen i applikasjonen, må vi sette opp nødvendige avhengigheter.

Når Maven er vårt byggeverktøy, må vi bruke:

 org.apache.deltaspike.modules deltaspike-data-module-api 1.8.2 kompilere org.apache.deltaspike.modules deltaspike-data-module-impl 1.8.2 kjøretid 

Når vi bruker Gradle:

kjøretid 'org.apache.deltaspike.modules: deltaspike-data-module-impl' kompilere 'org.apache.deltaspike.modules: deltaspike-data-module-api' 

Apache DeltaSpike datamodulartefakter er tilgjengelige på Maven Central:

• deltaspike-data-module-impl
• deltaspike-data-module-api

Til kjøre et program med datamodul, trenger vi også en JPA- og CDI-implementering tilgjengelig på kjøretid.

Selv om det er mulig å kjøre Apache DeltaSpike i Java SE-applikasjonen, vil den i de fleste tilfeller distribueres på applikasjonsserveren (f.eks. Wildfly eller WebSphere).

Søknadsservere har full Jakarta EE-støtte, så vi trenger ikke gjøre noe mer. I tilfelle Java SE-applikasjon, må vi tilby disse implementeringene (f.eks. Ved å legge til avhengigheter i Hibernate og JBoss Weld).

Deretter dekker vi også nødvendig konfigurasjon for EntityManager.

2.2. Entity Manager-konfigurasjon

De Datamodul krever EntityManager som skal injiseres over CDI.

Vi kan oppnå dette ved å bruke en CDI-produsent:

offentlig klasse EntityManagerProducer {@PersistenceContext (unitName = "primary") private EntityManager entityManager; @ApplicationScoped @Produces offentlig EntityManager getEntityManager () {return entityManager; }}

Ovennevnte kode forutsetter at vi har utholdenhetsenhet med navn hoved definert i persistence.xml fil.

La oss se nedenfor som et eksempel på definisjon:

 java: jboss / datakilder / baeldung-jee7-seedDS 

I dette eksemplet bruker utholdenhetsenheten JTA-transaksjonstype, noe som betyr at vi må tilby en transaksjonsstrategi vi skal bruke.

2.3. Transaksjonsstrategi

I tilfelle vi bruker JTA-transaksjonstype for datakilden vår, må vi definere transaksjonsstrategi som skal brukes i Apache DeltaSpike-repositoriene.. Vi kan gjøre det inne apache-deltaspike.properties fil (under META-INF katalog):

globalAlternatives.org.apache.deltaspike.jpa.spi.transaction.TransactionStrategy = org.apache.deltaspike.jpa.impl.transaction.ContainerManagedTransactionStrategy

Det er fire typer transaksjonsstrategier vi kan definere:

• BeanManagedUserTransactionStrategy
• ResourceLocalTransactionStrategy
• ContainerManagedTransactionStrategy
• EnvironmentAwareTransactionStrategy

Alle implementerer dem org.apache.deltaspike.jpa.spi.transaction.TransactionStrategy.

Dette var den siste delen av konfigurasjonen som kreves for datamodulen vår.

Deretter viser vi hvordan du implementerer depotmønsterklassene.

3. Lagerklasser

Når vi bruker Apache DeltaSpike datamodul hvilken som helst abstrakt klasse eller grensesnitt kan bli et depot klasse.

Alt vi trenger å gjøre er ålegg til en @Oppbevaringsstedkommentar med en forEnhet attributt som definerer JPA-enhet som depotet vårt skal håndtere:

@Entity public class User {// ...} @Repository (forEntity = User.class) offentlig grensesnitt SimpleUserRepository {// ...}

eller med en abstrakt klasse:

@Repository (forEntity = User.class) offentlig abstrakt klasse SimpleUserRepository {// ...} 

Datamodulen oppdager klasser (eller grensesnitt) med en slik kommentar, og den behandler metoder som er inne.

Det er få muligheter for å definere spørringen du skal utføre. Vi vil dekke en etter en snart i de følgende avsnittene.

4. Spørring fra metodenavn

Den første muligheten til definere et spørsmål er å bruke metodenavn som følger en definert navnekonvensjon.

Det ser ut som nedenfor:

(Enhet | Valgfritt | Liste | Strøm) (prefiks) (Eiendom [Comparator]) {Operator Property [Comparator]} 

Deretter vil vi fokusere på hver del av denne definisjonen.

4.1. Returtype

De return type definerer hovedsakelig hvor mange objekter spørringen kan returnere. Vi kan ikke definere én enhetstype som en returverdi i tilfelle forespørselen vår kan gi mer enn ett resultat.

Følgende metode gir et unntak i tilfelle det er mer enn ett Bruker med fornavn:

offentlig abstrakt Bruker findByFirstName (streng fornavn);

Det motsatte er ikke sant - vi kan definere en returverdi som en Samling selv om resultatet bare blir en enhet.

offentlig abstrakt samling findAnyByFirstName (streng fornavn);

Metodenavnprefikset som antyder en verdi som returtype (f.eks. finn noen) undertrykkes i tilfelle vi definerer returverdien som Samling.

Ovenstående spørring vil returnere alle Brukere med et fornavn som matcher til og med metodenavnets prefiks antyder noe annet.

Slike kombinasjoner (Samling returtype og et prefiks som antyder en enkeltverdiretur) bør unngås fordi koden ikke blir intuitiv og vanskelig å forstå.

Den neste delen viser flere detaljer om prefiks for metodenavn.

4.2. Prefiks for spørringsmetode

Prefiks definerer handlingen vi ønsker å utføre på depotet. Den mest nyttige er å finne enheter som samsvarer med gitte søkekriterier.

Det er mange prefikser for denne handlingen som findBy, finn noen, finn alle. For den detaljerte listen, vennligst sjekk den offisielle Apache DeltaSpike-dokumentasjonen:

offentlig abstrakt bruker findAnyByLastName (strengnavn);

Imidlertid er det også andre metodemaler som brukes til å telle og fjerne enheter. Vi kan telle alle rader i en tabell:

offentlig abstrakt int count ();

Også, fjerne metodemal eksisterer som vi kan legge til i depotet vårt:

offentlig abstrakt ugyldig fjerne (brukerbruker);

Støtte for countBy og removeBy metodeprefikser blir lagt til i neste versjon av Apache DeltaSpike 1.9.0.

Den neste delen viser hvordan vi kan legge til flere attributter til spørsmålene.

4.3. Spørring med mange eiendommer

I spørringen kan vi bruke mange eiendommer kombinert med og operatører.

offentlig abstrakt samling FindByFirstNameAndLastName (streng fornavn, streng etternavn); offentlig abstrakt Samling findByFirstNameOrLastName (streng fornavn, streng etternavn); 

Vi kan kombinere så mange egenskaper som vi vil. Søk etter nestede eiendommer er også tilgjengelig, som vi viser neste.

4.4. Spørring med nestede egenskaper

De spørring kan også bruke nestede egenskaper.

I det følgende eksemplet Bruker enhet har en adresseegenskap av typen Adresse og Adresse enhet har en by eiendom:

@Entity offentlig klasse Adresse {privat strengby; // ...} @Entity offentlig klasse bruker {@OneToOne privat adresse adresse; // ...} offentlig abstrakt samling findByAddress_city (strengby);

4.5. Bestill i spørringen

DeltaSpike tillater oss å definere en rekkefølge som resultatet skal returneres i. Vi kan definere både stigende og synkende rekkefølge:

offentlig abstrakt Liste findAllOrderByFirstNameAsc ();

Som vist fremfor alt vi må gjøre er å legge til en del i metodenavnet som inneholder eiendomsnavnet vi vil sortere etter og kortnavnet for ordreretningen.

Vi kan enkelt kombinere mange bestillinger:

offentlig abstrakt Liste findAllOrderByFirstNameAscLastNameDesc (); 

Deretter viser vi hvordan du kan begrense størrelsen på spørringsresultatet.

4.6. Begrens spørringsresultatstørrelse og paginering

Det er brukstilfeller når vi vil hente noen få første rader fra hele resultatet. Det er såkalt spørringsgrense. Det er også greit med datamodulen:

offentlig abstrakt samling FindTop2OrderByFirstNameAsc (); offentlig abstrakt Samling findFirst2OrderByFirstNameAsc ();

Først og topp kan brukes om hverandre.

Vi kan da aktiver spørringspaginering ved å oppgi to ekstra parametere: @FirstResult og @MaxResult:

offentlig abstrakt samling FindAllOrderByFirstNameAsc (@FirstResult int start, @MaxResults int size);

Vi definerte allerede mange metoder i depotet. Noen av dem er generiske og bør defineres en gang og brukes av hvert depot.

Apache DeltaSpike gir få grunnleggende typer som vi kan bruke for å ha mange metoder ute av esken.

I neste avsnitt vil vi fokusere på hvordan du gjør dette.

5. Grunnleggende depottyper

Til få noen grunnleggende depotmetoder, vårt depot skal utvide grunnleggende typen levert av Apache DeltaSpike. Det er noen av dem som EntityRepository, FullEntityRepository, etc.:

@Repository offentlige grensesnitt UserRepository utvider FullEntityRepository {// ...}

Eller bruke en abstrakt klasse:

@Repository offentlig abstrakt klasse UserRepository utvider AbstractEntityRepository {// ...} 

Ovennevnte implementering gir oss mange metoder uten å skrive flere kodelinjer, så vi fikk det vi ønsket - vi reduserer kjeleplatekoden massivt.

I tilfelle vi bruker basearkivstype, er det ikke nødvendig å sende inn en ekstra forEnhet attributtverdi til vår @Oppbevaringssted kommentar.

Når vi bruker abstrakte klasser i stedet for grensesnitt for repositoriene våre, får vi en ekstra mulighet til å lage et tilpasset spørsmål.

Abstrakte basislagerklasser, f.eks. AbstractEntityRepository gir oss tilgang til felt (via getters) eller verktøymetoder som vi kan bruke til å lage et spørsmål:

offentlig liste findByFirstName (streng fornavn) {return typedQuery ("velg u fra bruker u hvor u.firstName =? 1") .setParameter (1, fornavn) .getResultList (); } 

I eksemplet ovenfor brukte vi a typedQuery verktøymetode for å lage en tilpasset implementering.

Den siste muligheten for å opprette et spørsmål er å bruke @Spørsmål kommentar som vi skal vise neste.

6. @Spørsmål Kommentar

SQL spørring å utføre kan også defineres med @Spørsmål kommentar. Det ligner veldig på vårløsningen. Vi må legge til en kommentar til metoden med SQL-spørring som verdi.

Som standard er dette et JPQL-spørsmål:

@Query ("velg u fra bruker u hvor u.firstName =? 1") offentlig abstrakt samling findUsersWithFirstName (streng fornavn); 

Som i eksemplet ovenfor kan vi enkelt overføre parametere til spørringen via en indeks.

I tilfelle vi ønsker å sende spørring via innfødt SQL i stedet for JPQL, må vi definere ekstra spørringsattributt - er innfødt med sann verdi:

@Query (value = "select * from User where firstName =? 1", isNative = true) public abstract Collection findUsersWithFirstNameNative (Streng fornavn);

7. Konklusjon

I denne artikkelen tok vi for oss den grunnleggende definisjonen av Apache DeltaSpike, og vi fokuserte på den spennende delen - Data-modul. Det ligner veldig på Spring Data Project.

Vi undersøkte hvordan vi kunne implementere depotmønsteret. Vi introduserte også tre muligheter for å definere et spørsmål å utføre.

Som alltid er de komplette kodeeksemplene som brukes i denne artikkelen tilgjengelig på Github.