Hibernate Validation Annotationen für Entity Beans
Einer der wohl größten Vorteile neben den JPA Annotationen für die Beschreibung des Datenbankschemas bei der Verwendung von EJB 3 Entity Beans ist wohl die Nutzung von Validierungs-Annotationen (Constraints) direkt an den Attributen Entity Bean. Verwendet man Hibernate als JPA Implementierung kann man auf ein ganze Menge vordefinierter Validatoren zurückgreifen die direkt verfügbar und durch ihre Namen auch selbsterklärend sind.
So könnte z.B. die Entity Bean “User” wie folgt aussehen:
@Entity public class User { @Id private Long id; @Length(min = 5, max = 50) @Pattern(regex="[a-zA-Z0-9]+") @NotNull private String name; @Email @NotNull private String email; @Past private Date birthday; // Getter & Setter }
Der Hibernate Validator arbeitet auf zwei Ebenen mit den Constraints. Zum einen die für Anwendungen sehr hilfreiche Funktion des “In-Memory-Checks” für Instanzen. In diesem Fall wird noch vor der eigentlichen Datenbank Operation gegen die konfigurierten Constraints geprüft. Zum anderen können ein paar Hibernate Constraints direkt in das Datenbankschema übernommen und somit noch einmal von der Datenbank selbst geprüft werden.
Im folgenden noch die Tabelle aller vordefinierten Hibernate Validation Annotationen:
| Annotation | Überprüfung auf | DB Schema Anpassung |
@Length(max=,min=)
|
gilt für ein String Attribut und prüft die Anzahl der Zeichen | Spaltenlänge mit max versehen |
@Max(value=)
|
gilt für eine Zahl (oder eine String welcher eine Zahl repräsentiert) und prüft ob der Wert kleiner oder gleich der Angabe ist | fügt “check” Constraint der Spalte hinzu |
@Min(value=)
|
gilt für eine Zahl (oder eine String welcher eine Zahl repräsentiert) und prüft ob der Wert größer oder gleich der Angabe ist | fügt Check Constraint der Spalte hinzu |
| @NotNull |
gilt für alle Attribute und prüft ob der Wert gesetzt ist (nicht null)
|
Not Null Constraint an Spalte |
@NotEmpty
|
gilt für alle Attribute und prüft ob der Wert nicht null und zudem nicht leer (Leerstring) ist
|
fügt für einen String das Not Null Constraint an Spalte |
@Past
|
gilt für Date oder Calendar Typen und prüft ob das Datum in der Vergangenheit liegt
|
fügt Check Constraint der Spalte hinzu |
@Future
|
gilt für Date oder Calendar Typen und prüft ob das Datum in der Zukunft liegt
|
- |
@Pattern(regex="")
|
gilt für alle Attribute und prüft ob der Wert dem regulären Ausdruck entspricht | - |
@Range(min=, max=)
|
gilt für eine Zahl (oder eine String welcher eine Zahl repräsentiert) und prüft ob die Zahl in dem Wertebereich zwischen min und max (inklusive) liegt | fügt Check Constraint der Spalte hinzu |
@Size(min=, max=)
|
gilt für ein Array, Collection oder Map und prüft ob die Anzahl der enthaltenen Elemente zwischen min und max (inklusive) liegt | - |
@Email
|
gilt für einen String und prüft ob dieser einer E-Mail Beschreibung laut Spezifikation entspricht | - |
@CreditCardNumber
|
gilt für einen String und prüft ob dieser einer Kreditkartennummer entspricht | - |
@Valid
|
gilt für ein Objekt, Collection oder Array und prüft deren Validierung ab (bei Collection oder Array rekursiv alle Elemente) | - |
Mit diesem Set an Hibernate Annotationen dürfte man die normalen und häufigsten Anforderungen an die Validierung erfüllt werden. Das mächtigste Constraint dürfte die @Pattern(regex="") sein, die man mit regulären Ausdrücken befüllen kann.
Als letzte Information in diesem Artikel noch der Hinweis, dass für jede Hibernate Annotation ein Standardfehlertext existiert, der aber angepasst werden kann. So kann jede gesetzte Annotation mit einer eigenen Fehlermeldung versehen werden. Dafür dient das Attribut message und wird in der Exception oder dem InvalidValue Objekt bei einer Constraint Verletzung gesetzt. Hier noch ein Beispiel für das Verwenden von Nachrichten:
@Length(min = 5, max = 50, message="Username muss zwischen 5 und 50 Zeichen lang sein") private String name; @Past(message="Der Geburtstag muss in der Vergangenheit liegen") private Date birthday;
Natürlich kann auch internationalisiert werden. Dazu einfach eine ValidatorMessages.properties bzw. ValidatorMessages_de.properties erstellen und im Classpath ablegen und die entsprechenden keys anpassen oder eigene erstellen:
bdayPast=Der Geburtstag muss in der Vergangenheit liegen
Und in der Klassen dann die Keys mit geschweiften Klammern verwenden:
@Length(min = 5, max = 50, message="{usernameLength}") private String name; @Past(message="{bdayPast}") private Date birthday;
Selbst wenn man die Validierung noch nicht im Frontend eingebaut oder in der Anwendung verwendet lohnt es sich diese in der Entity Bean zu konfigurieren. Neben den direkt im Datenbankschema eingebauten Constraints dient es bei der Entwicklung und Verwendung der Entity Beans absolut der Übersicht und zentralisiert die Vorgaben der Validierung.
Wenn du Fragen oder Anregungen zum Post hast, dann hinterlasse doch einen Kommentar oder wenn du weiterhin Artikel von Javathreads lesen möchtest, dann abonniere den RSS Feed und sehe direkt in deinem Feed Reader die nächsten Artikel.
Ähnliche Artikel, die dich interessieren könnten:
Kommentare
Bei mir liegen die eigenen angepassten Validator Messages in der normalen messages_de.properties. Die messages Properties werden bei einer JSF Anwendung in der faces.config im Tag
Ich verwende Seam und da kann ich die messages auch noch konfigurieren.
Die messages_de.properties liegt bei mir direkt im source Verzeichnis.
Thanks for publishing regarding it. There’s a bunch of helpful details on the world wide web. You’ve got many which data right here on your web site. I’m amazed – I try to retain a couple blogs considerably ongoing, but it can be hard at times. You’ve done a big job with it one. I will need to pay a visit to your blog once again really quickly
I learned your weblog site on google and verify a few of your early posts. Continue to maintain up the very excellent function. I just additional up your Rss feed to my Msn Information Reader. Searching for forward to reading a lot more from you later on!?
wie soll ich meine Konfiguration .xml ändern um eigene
ValidatorMessages.properties zu verwenden. Ich habe im internet nachgeforsch und das folgende gefunden aber leider funktioniert nicht.
META-INF/validation_errors