Dvaletilstandsspecifikke begrænsninger

1. Oversigt

I denne vejledning vil vi gennemgå begrænsninger i dvaletilstand, som er indbygget i dvaletilstand, men er uden for Bean Validation-specifikationen.

For en oversigt over Bean Validation henvises til vores artikel om Java Bean Validation Basics.

2. Opsætning af dvaletilstandsvalidator

I det mindste, vi skal tilføje Hibernate Validator til vores afhængigheder:

 org.hibernate.validator hibernate-validator 6.0.16.Final 

Bemærk, at Hibernate Validator ikke afhænger af Hibernate, ORM, som vi har dækket i mange andre artikler.

Derudover gælder nogle af de kommentarer, som vi introducerer, kun hvis vores projekt bruger visse biblioteker. Så for hver enkelt af dem angiver vi de nødvendige afhængigheder.

3. Validering af penge-relaterede værdier

3.1. Validering af kreditkortnumre

Gyldige kreditkortnumre skal opfylde et kontrolsum, som vi beregner ved hjælp af Luhns algoritme. Det @Kreditkortnummer begrænsning lykkes, når en streng tilfredsstiller kontrolsummen.

@Kreditkortnummer udfører ingen anden kontrol af inputstrengen. Især kontrollerer den ikke længden af ​​input. Derfor kan den kun registrere numre, der er ugyldige på grund af en lille skrivefejl.

Bemærk, at begrænsningen som standard mislykkes, hvis strengen indeholder tegn, der ikke er cifre, men vi kan fortælle det at ignorere dem:

@CreditCardNumber (ignoreNonDigitCharacters = true) private String lenientCreditCardNumber;

Derefter kan vi inkludere tegn som mellemrum eller bindestreger:

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

3.2. Validering af monetære værdier

Det @Betalingsmiddel validator kontrollerer, om et givet pengebeløb er i den angivne valuta:

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

Klassen Monetært beløb er en del af Java Money. Derfor, @Betalingsmiddel gælder kun, når en Java Money-implementering er tilgængelig.

Når vi har indstillet Java Money korrekt, kan vi kontrollere begrænsningen:

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

4. Validering af intervaller

4.1. Numeriske og monetære områder

Beanvalideringsspecifikationen definerer flere begrænsninger, som vi kan håndhæve på numeriske felter. Udover disse giver Hibernate Validator en praktisk kommentar, @Rækkevidde, at fungerer som en kombination af @Min og @Max,matchende et interval inklusiv:

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

Synes godt om @Min og @Max, @Rækkevidde kan anvendes på felter af primitive taltyper og deres indpakninger; BigInteger og BigDecimal, Snor repræsentationer af ovenstående og endelig Monetær værdi felter.

4.2. Varighed af tid

Ud over standard JSR 380-annoteringer for værdier, der repræsenterer tidspunkter, inkluderer Hibernate Validator begrænsninger for Varigheds også. Sørg for at tjekke ud Periode og Varighed klasser af Java Time først.

Så, vi kan håndhæve minimums- og maksimumvarigheder på en ejendom:

@DurationMin (dage = 1, timer = 2) @DurationMax (dage = 2, timer = 1) privat Varighed varighed;

Selvom vi ikke viste dem alle her, har kommentaren parametre for alle tidsenheder fra nanosekunder til dage.

Bemærk, at som standard minimums- og maksimumværdier er inklusive. Det vil sige, at en værdi, der er nøjagtig den samme som minimum eller maksimum, vil godkende valideringen.

Hvis vi ønsker, at grænseværdier skal være ugyldige, definerer vi i stedet inklusive ejendom skal være falsk:

@DurationMax (minutter = 30, inklusive = falsk)

5. Validering af strenge

5.1. Strenglængde

Vi kan bruge to lidt forskellige begrænsninger til at håndhæve, at en streng har en bestemt længde.

Generelt vil vi sikre en strenglængde i tegn - den, vi måler med længde metode - er mellem et minimum og et maksimum. I så fald bruger vi @Længde på en strengegenskab eller et felt:

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

På grund af Unicodes indviklede karakter er længden i tegn og længden i kodepunkter dog nogle gange forskellige. Når vi vil kontrollere sidstnævnte, bruger vi @CodePointLængde:

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

For eksempel er strengen “aa \ uD835 \ uDD0A” 4 tegn lang, men den indeholder kun 3 kodepunkter, så den fejler den første begrænsning og videregiver den anden.

Også med begge kommentarer kan vi udelade minimums- eller maksimumværdien.

5.2. Kontrol af strenge af cifre

Vi har allerede set, hvordan vi kontrollerer, at en streng er et gyldigt kreditkortnummer. Hibernate Validator indeholder dog flere andre begrænsninger for cifre.

Den første, vi gennemgår, er @LuhnCheck. Dette er den generaliserede version af @Kreditkortnummer, i det det udfører den samme kontrol, men giver mulighed for yderligere parametre:

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

Her har vi vist standardværdierne for parametrene, så ovenstående svarer til en simpel @LuhnCheck kommentar.

Men som vi kan se, kan vi udføre kontrollen på en substring (startIndex og endIndex) og fortæl begrænsningen, hvilket ciffer der er kontrolsumcifferet, hvor -1 betyder det sidste i det afkrydsede underlag.

Andre interessante begrænsninger inkluderer modulo 10-kontrollen (@ Mod10Check) og modulo 11-kontrollen (@ Mod11Check), der typisk bruges til stregkoder og andre koder såsom ISBN.

I disse specifikke tilfælde giver Hibernate Validator imidlertid en begrænsning til at validere ISBN-koder, @ISBN, samt en @EAN begrænsning for EAN-stregkoder.

5.3. URL- og HTML-validering

Det @Url begrænsning verificerer, at en streng er en gyldig repræsentation af en URL. Derudover kan vi kontrollere, at den specifikke komponent i URL'en har en bestemt værdi:

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

Vi kan således kontrollere protokollen, værten og porten. Hvis det ikke er tilstrækkeligt, er der en regexp ejendom, som vi kan bruge til at matche URL'en mod et regulært udtryk.

Vi kan også kontrollere, at en ejendom indeholder "sikker" HTML-kode (for eksempel uden script-tags):

@ SafeHtml private String html;

@SafeHtml bruger JSoup-biblioteket, som skal inkluderes i vores afhængigheder.

Vi kan skræddersy HTML-desinficering til vores behov ved hjælp af indbyggede hvidlister til tag ( hvidliste annotationens egenskab) og inkluderer yderligere tags og attributter ( yderligere mærker og additionalTagsWithAttributes parametre).

6. Andre begrænsninger

Lad os kort nævne, at Hibernate Validator inkluderer nogle lands- og landespecifikke begrænsninger, især for nogle brasilianske og polske identifikationsnumre, skatteyderkoder og lignende. Se det relevante afsnit i dokumentationen for en komplet liste.

Vi kan også kontrollere, at en samling ikke indeholder dubletter med @UniqueElements.

Endelig kan vi i komplekse sager, der ikke er dækket af eksisterende kommentarer, påberåbe et script skrevet i en JSR-223-kompatibel scriptmotor. Vi har naturligvis berørt JSR-223 i vores artikel om Nashorn, JavaScript-implementeringen inkluderet i moderne JVM'er.

I dette tilfælde er kommentaren på klasseniveau, og scriptet påberåbes på hele forekomsten, videregivet som variablen _det her:

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

Derefter kan vi kontrollere begrænsningen for hele forekomsten:

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

7. Konklusion

I denne artikel har vi listet begrænsningerne i Hibernate Validator, der går ud over det minimale sæt, der er defineret i Bean Validation-specifikationen.

Implementeringen af ​​alle disse eksempler og kodestykker findes på GitHub.