Spesifikke begrensninger for dvalemodusvalidator

1. Oversikt

I denne veiledningen skal vi gjennomgå begrensninger for dvalemodus, som er innebygd i dvalemodus, men som ligger utenfor spesifikasjonen for bønnevalidering.

For en oversikt over Bean Validation, se artikkelen vår om Java Bean Validation Basics.

2. Hibernate Validator Setup

I det minste, vi bør legge til dvalemodus i avhengighet:

 org.hibernate.validator hibernate-validator 6.0.16.Final 

Merk at dvalemodus ikke er avhengig av dvalemodus, ORM, som vi har dekket i mange andre artikler.

I tillegg gjelder noen av kommentarene vi introduserer bare hvis prosjektet vårt bruker visse biblioteker. Så for hver enkelt av disse vil vi indikere de nødvendige avhengighetene.

3. Validering av pengerelaterte verdier

3.1. Validering av kredittkortnumre

Gyldige kredittkortnumre må tilfredsstille et kontrollsum, som vi beregner ved hjelp av Luhns algoritme. De @Kreditt kort nummer begrensning lykkes når en streng tilfredsstiller kontrollsummen.

@Kreditt kort nummer utfører ingen andre kontroller på inngangsstrengen. Spesielt sjekker den ikke lengden på inngangen. Derfor kan den bare oppdage tall som er ugyldige på grunn av en liten skrivefeil.

Merk at begrensningen mislykkes som standard hvis strengen inneholder tegn som ikke er sifre, men vi kan fortelle den å ignorere dem:

@CreditCardNumber (ignoreNonDigitCharacters = true) privat streng lenientCreditCardNumber;

Deretter kan vi inkludere tegn som mellomrom eller bindestreker:

validations.setLenientCreditCardNumber ("7992-7398-713"); constraintViolations = validator.validateProperty (valideringer, "lenientCreditCardNumber"); assertTrue (constraintViolations.isEmpty ());

3.2. Validering av monetære verdier

De @Valuta validator sjekker om et gitt pengebeløp er i den angitte valutaen:

@Currency ("EUR") privat MonetaryAmount-saldo;

Klassen Monetært beløp er en del av Java Money. Derfor, @Valuta gjelder bare når en Java Money-implementering er tilgjengelig.

Når vi har satt opp Java Money riktig, kan vi sjekke begrensningen:

bean.setBalance (Money.of (ny BigDecimal (100.0), Monetary.getCurrency ("EUR"))); constraintViolations = validator.validateProperty (bønne, "balanse"); assertEquals (0, constraintViolations.size ());

4. Validerende områder

4.1. Numeriske og monetære områder

Beanvalideringsspesifikasjonen definerer flere begrensninger som vi kan håndheve på numeriske felt. I tillegg til disse gir Hibernate Validator en praktisk kommentar, @Område, det fungerer som en kombinasjon av @Min og @Max,som matcher et utvalg inkludert:

@Range (min = 0, max = 100) private BigDecimal prosent;

Som @Min og @Max, @Område gjelder på felt av primitive talltyper og deres innpakninger; BigInteger og BigDecimal, String fremstillinger av ovennevnte, og til slutt MonetaryValue Enger.

4.2. Varighet av tid

I tillegg til standard JSR 380-merknader for verdier som representerer tidspunkter, inkluderer Hibernate Validator begrensninger for Varighets også. Sørg for å sjekke ut Periode og Varighet klasser av Java Time først.

Så, vi kan håndheve minimum og maksimal varighet på en eiendom:

@DurationMin (dager = 1, timer = 2) @DurationMax (dager = 2, timer = 1) privat Varighet;

Selv om vi ikke viste dem alle her, har kommentaren parametere for alle tidsenheter fra nanosekunder til dager.

Vær oppmerksom på at som standard minimums- og maksimumsverdier er inkludert. Det vil si at en verdi som er nøyaktig den samme som minimum eller maksimum vil bestå validering.

Hvis vi vil at grenseverdiene skal være ugyldige, definerer vi i stedet inklusive eiendom å være falsk:

@DurationMax (minutter = 30, inkludert = usann)

5. Validerende strenger

5.1. Strenglengde

Vi kan bruke to litt forskjellige begrensninger for å håndheve at en streng er av en viss lengde.

Generelt sett vil vi sikre en strenglengde i tegn - den vi måler med lengde metode - er mellom et minimum og et maksimum. I så fall bruker vi @Lengde på en strengegenskap eller -felt:

@Length (min = 1, max = 3) privat String someString;

På grunn av komplikasjonene til Unicode, varierer imidlertid lengden i tegn og lengden i kodepunkter. Når vi vil sjekke sistnevnte, bruker vi @CodePointLength:

@CodePointLength (min = 1, max = 3) privat String someString;

For eksempel er strengen “aa \ uD835 \ uDD0A” fire tegn lang, men den inneholder bare 3 kodepunkter, så den vil mislykkes i den første begrensningen og passerer den andre.

Med begge kommentarene kan vi også utelate minimums- eller maksimumsverdien.

5.2. Sjekker på strenger av sifre

Vi har allerede sett hvordan vi kan kontrollere at en streng er et gyldig kredittkortnummer. Hibernate Validator inneholder imidlertid flere andre begrensninger for strenger av sifre.

Den første vi vurderer er @LuhnCheck. Dette er den generaliserte versjonen av @Kreditt kort nummer, i det den utfører den samme kontrollen, men tillater flere parametere:

@LuhnCheck (startIndex = 0, endIndex = Integer.MAX_VALUE, checkDigitIndex = -1) privat String someString;

Her har vi vist standardverdiene til parametrene, så ovenstående tilsvarer en enkel @LuhnCheck kommentar.

Men som vi kan se, kan vi utføre kontrollen på en understreng (startIndex og endIndex) og fortell begrensningen hvilket siffer som er sjekksummen, med -1 som betyr det siste i det avmerkede underlaget.

Andre interessante begrensninger inkluderer modulo 10-sjekken (@ Mod10Check) og modulo 11-kontrollen (@ Mod11Check), som vanligvis brukes til strekkoder og andre koder som ISBN.

I de spesifikke tilfellene gir Hibernate Validator imidlertid en begrensning for å validere ISBN-koder, @ISBN, samt en @EAN begrensning for EAN-strekkoder.

5.3. URL- og HTML-validering

De @Url begrensning verifiserer at en streng er en gyldig representasjon av en URL. I tillegg kan vi sjekke at spesifikk komponent av URL-en har en viss verdi:

@URL (protokoll = "https") privat String url;

Vi kan dermed sjekke protokollen, verten og porten. Hvis det ikke er tilstrekkelig, er det en regexp egenskap som vi kan bruke til å matche URL-en mot et vanlig uttrykk.

Vi kan også bekrefte at en eiendom inneholder en "sikker" HTML-kode (for eksempel uten skriptkoder):

@ SafeHtml private String html;

@SafeHtml bruker JSoup-biblioteket, som må inkluderes i våre avhengigheter.

Vi kan skreddersy HTML-desinfisering etter våre behov ved hjelp av innebygde hvitelister for tagger ( hviteliste merknaden) og inkluderer tilleggskoder og attributter ( tilleggskoder og additionalTagsWithAttributes parametere).

6. Andre begrensninger

La oss nevne kort at Hibernate Validator inkluderer noen lands- og stedsspesifikke begrensninger, spesielt for noen brasilianske og polske identifikasjonsnumre, skattebetalerkoder og lignende. Se den relevante delen av dokumentasjonen for en fullstendig liste.

Vi kan også sjekke at en samling ikke inneholder duplikater med @UniqueElements.

Til slutt, for komplekse saker som ikke dekkes av eksisterende kommentarer, kan vi påberope et skript skrevet i en JSR-223-kompatibel skriptmotor. Vi har selvfølgelig berørt JSR-223 i vår artikkel om Nashorn, JavaScript-implementeringen inkludert i moderne JVM.

I dette tilfellet er merknaden på klassenivå, og skriptet påkalles på hele forekomsten, sendes som variabelen _dette:

@ScriptAssert (lang = "nashorn", script = "_this.valid") offentlig klasse AdditionalValidations {private boolean valid = true; // standard getters og setters}

Deretter kan vi sjekke begrensningen for hele forekomsten:

bean.setValid (false); constraintViolations = validator.validate (bean); assertEquals (1, constraintViolations.size ());

7. Konklusjon

I denne artikkelen har vi listet opp begrensningene i Hibernate Validator som går utover det minimale settet som er definert i Bean Validation-spesifikasjonen.

Implementeringen av alle disse eksemplene og kodebiter finner du på GitHub.


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