Hibernate Validation Annotationen für Entity Beans

Von Markus Kühle
02.06.2009

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:

usernameLength=Username muss zwischen 5 und 50 Zeichen lang sein
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.

Artikel per E-Mail empfehlen Artikel per E-Mail empfehlen
Framework
Tags: ,

Wenn du Fragen oder Anregungen zum Post hast, dann hinterlasse doch ein 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

Bisher keine Kommentare vorhanden.

Hinterlasse ein Kommentar