Validierung

Validierung in Webanwendungen ist immer ein heißes Thema. Wird nur im Business-Layer validiert? Oder nur im UI-Layer, sprich mit den JSF-Validatoren? Dieses Thema wird selbst von erfahrenen Software-Architekten regelmässig und intensiv diskutiert ;-)
Korrekterweise muss mindestens in der Business-Schicht validiert werden. Eine Validierung im UI kann optional draufgesetzt werden. Das Problem ist nur, dass dann die Validierungsregeln redundant, vermutlich auch noch unter Verwendung unterschiedlicher Technologien, vorliegen.

JSF 2.0 geht hier neue Wege. Zusammen mit dem JSR-303 (Bean Validation) werden künftig Metadaten in Form von Annotations direkt an der Klasse angebracht und können in verschiedenen Layern dann verwendet werden. JSF 2.0 schaut beim Validieren von Managed Beans nach, ob an einer Eigenschaft JSR-303-kompatible Annotationen vorhanden sind.

Ein kleiner Hinweis noch: Damit auch null-Werte im Modell landen, obwohl in einem Eingabefeld ein Leerstring eingegeben wurde, kann in der web.xml ein Kontextparameter javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL eingetragen werden.

Der JSR-303 (Bean Validation API)
Der JSR-303 schickt sich an, einen Standard für die Validierung von Beans zu sein. Validierung ist ein zentrales Thema jeder Business-Anwendung, kommt sie zudem auch noch in verschiedenen Schichten vor. Zunächst wird meist in der Oberfläche eine erste Validierung durchgeführt. Anschließend wird dann aus dem UI-Controller eine Business-Funktionalität aufgerufen. In dieser muss natürlich auch nochmals validiert werden. Zu guter Letzt wird ein Bean dann noch persistiert, was erneut eine Validierung voraussetzt.
In der Vergangenheit kamen auf den verschiedenen Layern zum Teil unterschiedliche Technologien zum Einsatz, was zu Redundanzen oder - schlimmer - sogar zu unterschiedlichen Ergebnissen in der Validierung führte.
Um diesen Diskrepanzen vorzubeugen, gab es in der Vergangenheit durch verschiedene Frameworks bereits den Ansatz, die Validierung an einer zentralen Stelle zu definieren und in den jeweiligen Layern darauf zuzugreifen. Hibernate Validator beispielsweise führte Annotations ein, Jakarta Commons Validator definierte eine zentrale XML-Datei.

Mit dem JSR-303 wurde jetzt erstmal eine standardisierte API erarbeitet, mit der genau diese Anforderung umgesetzt werden kann - die Validierungslogik ist an einer zentralen Stelle, nämlich an der Klasse selbst zu finden.

Installation
JSF 2.0 unterstützt JSR-303, allerdings müssen die dazu notwendigen Bibliotheken ggf. separat in das Projekt mit eingebunden werden. Als Implementierung kann beispielsweise Hibernate Validator verwendet werden. Dies ist die Referenzimplementierung. Eine weitere Implementierung wäre agimatec. Im Folgenden verwende ich allerdings die Hibernate Variante. Alle notwendigen Bibliotheken können über die JBoss.org Website bezogen werden und werden einfach in das WEB-INF/lib Verzeichnis mit aufgenommen. Sind die Bibliotheken im Projekt eingebunden, kann mit den entsprechenden Annotations gearbeitet werden. JSF erkennt eine JSR-303 annotierte Klasse und führt in der Lifecycle-Phase "Process Validations" die Validierungen durch und zeigt Fehlermeldungen an.

Verwendung von Beans Validation
Der JSR-303 definiert sogenannte Contstraint-Annotationen, die direkt am Modell angehängt werden können. Hier ein erstes Beispiel:

public class ValidateBean {

   @Size(min=3)
   private String lastname;
   ...
}

In diesem Beispiel wird festgelegt, dass eine Variable "lastname" mindestens 3 Zeichen lang sein muss. Eine Annotation wäre prinzipiell auch an den Getter-Methoden möglich. Es ist jedoch ratsam, sich für eine der beiden Varianten zu entscheiden, da es ansonsten zu einer doppelten Validierung kommen könnte.
Folgend ein paar weitere Annotations, die standardmässig im JSR-303 erwähnt sind. Es ist natürlich auch vorgesehen, weitere Contraint-Annotations zu erstellen, aber davon sehen wir jetzt einmal ab ;-)

@AssertFalse
@DecimalMax
@Digists
@Future
@Max
@Min
@NotNull
@Past
@Pattern
@Size
@Valid

Abschließend sei noch erwähnt, dass die Bean Validation API auch eine sogenannte Group Validiation (Gruppenvalidierung) vorsieht. So kann es je nach Situation unterschiedliche Anforderungen an die Validierung eines Beans geben. Standardmässig gehören alle Constraints der Default-Gruppe an. Mit dem Attribut "groups" kann ein Constraint einer Gruppe zugeordnet werden.

Zurück zur Übersichtsseite