Kolumne: EnterpriseTales

Einer für alle – alle für einen: Bean Validation 1.1

Lars Röwekamp und Matthias Weßendorf

Damit eine möglichst sinnvolle Darstellung von Validierungsfehlern ermöglicht wird, stellt Bean Validation einen ParameterNameProvider zur Verfügung, der den Namen des fehlerhaften Parameters liefert. Da dieser in der Regel – zum Beispiel für den Endbenutzer einer Webanwendung – wenig Aussagekraft haben dürfte, soll es zukünftig ebenfalls möglich sein, eigene ParameterNameProvider zu implementieren und via Bootstraping-API- oder XML-Konfiguration (via parameter-name-provider-Tag) einzubinden.

Mit sehr hoher Wahrscheinlichkeit wird es für die Parameter-Validation auch einen Mechanismus geben, der Cross-Parameter Constraints erlaubt. Den aktuellen Stand der Diskussion dazu findet man unter [3] und [4]. Derzeit sind drei unterschiedliche Varianten im Gespräch. Die erste Variante legt nahe, auf einen Support vollständig zu verzichten. Die zweite Variante sieht ein Interface namens MethodConstraintValidator vor, dessen Methode isValid(…) beliebige Cross-Parameter-Validierungen ermöglicht und einen Zugriff auf die einzelnen Parameter via Signatur-Position erlaubt. Die dritte und letzte Variante verzichtet auf das Interface der zweiten Variante und setzt stattdessen eine isValid(…)-Methode voraus, die in ihrer Signatur mit der zu prüfenden Methode übereinstimmt. Auch eine Kombination aus der zweiten und dritten Variante ist durchaus denkbar. Neben den Parametern einer Methode kann – wie bereits beschrieben – auch deren Rückgabewert mit Constraints versehen werden. Das in Listing 2 aufgeführte Beispiel zeigt, dass neben „built-in“ Constraints selbstverständlich auch eigene Varianten zur Prüfung herangezogen werden können.

Listing 2

public class OrderService {

    private CreditCardProcessor creditCardProcessor;

    @ValidOnlineOrderService
    public OrderService(OnlineCreditCardProcessor creditCardProcessor) {
        this.creditCardProcessor = creditCardProcessor;
    }

    @ValidBatchOrderService
    public OrderService(BatchCreditCardProcessor creditCardProcessor) {
        this.creditCardProcessor = creditCardProcessor;
    }

    @NotNull
    @Size(min=1)
    public Set getCreditCardProcessors() { ... }

    @NotNull
    @Future
    public Date getNextAvailableDeliveryDate() { ... }
}

Eine Frage, die sich bei der Method-Level-Validation fast automatisch stellt, ist, wie es sich bei der Validierung von Methoden bei Vererbung verhält. Hier verweist die Spezifikation auf das Liskovsche Substitutionsprinzip [5] – es ist keine Schande, wenn man dieses erst nachschlagen muss – und legt fest, dass Parameter-Constraints in Subtypen nicht verstärkt und Return Value Constraints in Subtypen nicht geschwächt werden sollten.

Fazit

Dank Bean Validation ist eine einheitliche Validierung im gesamten Java EE/SE Stack möglich. Schichtenspezifische Lösungen werden obsolet. Eine derartige Lösung hat allerdings nur dann Aussicht auf Erfolg, wenn eine gute Integration mit anderen APIs gewährleistet ist. Dass dies funktioniert, hat Bean Validation bereits in der Version 1.0 am Beispiel von JSF und JPA bewiesen. JAX-RS, JAXB und weitere werden in der Version 1.1 folgen.

Ein weiterer Baustein für den zukünftigen Erfolg von Bean Validation stellt die Möglichkeit zur Validierung von Methoden-Parametern und -rückgabewerten dar. „Programming by Contract“ inklusive Pre- und Post-Conditions erlauben einen zentralen Validierungsansatz und ersparen so eine Menge redundanten Code. Ob dieses Feature allerdings bereits in Java EE 7 in den zugehörigen APIs integriert werden wird, steht noch in den Sternen. Der aktuelle Stand der Spezifikation – Early Draft – macht einen sehr guten Eindruck. Wir dürfen gespannt sein, was sich bis zur Final Version noch alles tut. In diesem Sinne: Stay tuned …

Lars Röwekamp ist Geschäftsführer der open knowledge GmbH und berät seit mehr als zehn Jahren Kunden in internationalen Projekten rund um das Thema Enterprise Computing (Twitter: @mobileLarson).

Matthias Weßendorf beschäftigt sich mit WebSocket, HTML5 und weiteren Themen rund um das Next Generation Web. Er bloggt gelegentlich auf matthiaswessendorf.wordpress.com
(Twitter: @mwessendorf).
Geschrieben von
Lars Röwekamp und Matthias Weßendorf
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.