Validator-spezifische Einschränkungen für den Ruhezustand

1. Übersicht

In diesem Lernprogramm werden die Einschränkungen für den Ruhezustand-Validator erläutert, die in den Ruhezustand-Validator integriert sind, jedoch außerhalb der Bean-Validierungsspezifikation liegen.

Eine Zusammenfassung der Bean-Validierung finden Sie in unserem Artikel zu den Grundlagen der Java-Bean-Validierung.

2. Hibernate Validator Setup

Zumindest sollten wir Hibernate Validator zu unseren Abhängigkeiten hinzufügen:

 org.hibernate.validator hibernate-validator 6.0.16.Final 

Beachten Sie, dass der Hibernate Validator nicht von Hibernate, dem ORM, abhängt, den wir in vielen anderen Artikeln behandelt haben.

Darüber hinaus gelten einige der Anmerkungen, die wir einführen, nur, wenn unser Projekt bestimmte Bibliotheken verwendet. Für jede dieser Angaben geben wir die erforderlichen Abhängigkeiten an.

3. Validierung geldbezogener Werte

3.1. Überprüfen der Kreditkartennummern

Gültige Kreditkartennummern müssen eine Prüfsumme erfüllen, die wir mit dem Luhn-Algorithmus berechnen. Die Einschränkung @CreditCardNumber ist erfolgreich, wenn eine Zeichenfolge die Prüfsumme erfüllt.

@CreditCardNumber führt keine weitere Überprüfung der Eingabezeichenfolge durch. Insbesondere wird die Länge der Eingabe nicht überprüft. Daher können nur Zahlen erkannt werden, die aufgrund eines kleinen Tippfehlers ungültig sind.

Beachten Sie, dass die Einschränkung standardmäßig fehlschlägt, wenn die Zeichenfolge Zeichen enthält, die keine Ziffern sind. Wir können sie jedoch anweisen, sie zu ignorieren:

@CreditCardNumber(ignoreNonDigitCharacters = true) private String lenientCreditCardNumber;

Dann können wir Zeichen wie Leerzeichen oder Bindestriche einfügen:

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

3.2. Geldwerte validieren

Der @ Currency- Validator prüft, ob ein bestimmter Geldbetrag in der angegebenen Währung vorliegt :

@Currency("EUR") private MonetaryAmount balance;

Die Klasse MonetaryAmount ist Teil von Java Money. Daher gilt @Currency nur, wenn eine Java Money-Implementierung verfügbar ist.

Sobald wir Java Money korrekt eingerichtet haben, können wir die Einschränkung überprüfen:

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

4. Bereiche validieren

4.1. Numerische und monetäre Bereiche

Die Bean-Validierungsspezifikation definiert mehrere Einschränkungen, die wir für numerische Felder erzwingen können. Darüber hinaus bietet Hibernate Validator eine praktische Anmerkung, @Range , die als Kombination von @Min und @Max fungiert und einen Bereich einschließlich einschließt:

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

Wie @Min und @Max ist @Range auf Felder primitiver Zahlentypen und deren Wrapper anwendbar. BigInteger und BigDecimal , String- Darstellungen der oben genannten und schließlich MonetaryValue- Felder.

4.2. Dauer

Zusätzlich zu den Standardanmerkungen für JSR 380 für Werte, die Zeitpunkte darstellen, enthält der Hibernate Validator auch Einschränkungen für die Dauer . Stellen Sie sicher, dass Sie zuerst die Perioden- und Dauerklassen von Java Time überprüfen .

So können wir minimale und maximale Dauer für eine Immobilie erzwingen:

@DurationMin(days = 1, hours = 2) @DurationMax(days = 2, hours = 1) private Duration duration;

Auch wenn wir hier nicht alle gezeigt haben, enthält die Annotation Parameter für alle Zeiteinheiten von Nanosekunden bis Tagen.

Bitte beachten Sie, dass Standard- und Maximalwerte standardmäßig inklusive sind. Das heißt, ein Wert, der genau dem Minimum oder Maximum entspricht, besteht die Validierung.

Wenn wir möchten, dass Grenzwerte ungültig sind, definieren wir stattdessen die Eigenschaft inclusive als falsch:

@DurationMax(minutes = 30, inclusive = false)

5. Validieren von Strings

5.1. String-Länge

Wir können zwei leicht unterschiedliche Einschränkungen verwenden, um zu erzwingen, dass eine Zeichenfolge eine bestimmte Länge hat.

Im Allgemeinen möchten wir sicherstellen, dass die Länge eines Strings in Zeichen - die Länge, die wir mit der Längenmethode messen - zwischen einem Minimum und einem Maximum liegt. In diesem Fall verwenden wir @Length für eine String-Eigenschaft oder ein String-Feld:

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

Aufgrund der Komplexität von Unicode unterscheiden sich jedoch manchmal die Länge in Zeichen und die Länge in Codepunkten. Wenn wir letzteres überprüfen möchten, verwenden wir @CodePointLength:

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

Beispielsweise ist die Zeichenfolge "aa \ uD835 \ uDD0A" 4 Zeichen lang, enthält jedoch nur 3 Codepunkte, sodass die erste Einschränkung fehlschlägt und die zweite übergeben wird.

Bei beiden Anmerkungen können wir auch den minimalen oder maximalen Wert weglassen.

5.2. Überprüft die Ziffernfolgen

Wir haben bereits gesehen, wie überprüft werden kann, ob eine Zeichenfolge eine gültige Kreditkartennummer ist. Der Hibernate Validator enthält jedoch mehrere andere Einschränkungen für Ziffernfolgen.

The first one we're reviewing is @LuhnCheck. This is the generalized version of @CreditCardNumber, in that it performs the same check, but allows for additional parameters:

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

Here, we've shown the default values of the parameters, so the above is equivalent to a simple @LuhnCheck annotation.

But, as we can see, we can perform the check on a substring (startIndex and endIndex) and tell the constraint which digit is the checksum digit, with -1 meaning the last one in the checked substring.

Other interesting constraints include the modulo 10 check (@Mod10Check) and the modulo 11 check (@Mod11Check), which are typically used for barcodes and other codes such as ISBN.

However, for those specific cases, Hibernate Validator happens to provide a constraint to validate ISBN codes, @ISBN, as well as an @EAN constraint for EAN barcodes.

5.3. URL and HTML Validation

The @Url constraint verifies that a string is a valid representation of a URL. Additionally, we can check that specific component of the URL has a certain value:

@URL(protocol = "https") private String url;

We can thus check the protocol, the host and the port. If that's not sufficient, there's a regexp property that we can use to match the URL against a regular expression.

We can also verify that a property contains “safe” HTML code (for example, without script tags):

@SafeHtml private String html;

@SafeHtml uses the JSoup library, which must be included in our dependencies.

We can tailor the HTML sanitization to our needs using built-in tag whitelists (the whitelist property of the annotation) and including additional tags and attributes (the additionalTags and additionalTagsWithAttributes parameters).

6. Other Constraints

Let's mention briefly that Hibernate Validator includes some country and locale-specific constraints, in particular for some Brazilian and Polish identification numbers, taxpayer codes and similar. Please refer to the relevant section of the documentation for a full list.

Also, we can check that a collection does not contain duplicates with @UniqueElements.

Finally, for complex cases not covered by existing annotations, we can invoke a script written in a JSR-223 compatible scripting engine. We've, of course, touched on JSR-223 in our article about Nashorn, the JavaScript implementation included in modern JVMs.

In this case, the annotation is at the class level, and the script is invoked on the entire instance, passed as the variable _this:

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

Then, we can check the constraint on the whole instance:

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

7. Fazit

In diesem Artikel haben wir die Einschränkungen in Hibernate Validator aufgelistet, die über den in der Bean Validation-Spezifikation definierten Mindestsatz hinausgehen.

Die Implementierung all dieser Beispiele und Codefragmente finden Sie auf GitHub.