06.02.07

Validation Framework Consolidation : where are we ?

Posted in Java at 8:20 am by skoobi

A Validation Framework Consolidation JSR was started last year. Like others, I appreciate the initiative, but given that there’s not much activity around this JSR, are we going to see some consolidation in this area anytime soon ?

Anyways, just a note explaining why I think it IS a good idea to consolidate the validation frameworks :

More and more people are now pushing Domain Driven Design (DDD), which is more or less a clear re-affirmation of what a good Object-Oriented Design of the Domain (e.g. business logic) is supposed to be. Basically, DDD is what everybody learned at school while studying UML (remember those Software engineering courses : Cars, Drivers,… ?), but nobody applied because it is too easy to forget about that and focus on the technical stuff.
Aspect-Oriented Development (AOP) is slowly becoming popular because if you want to express your domain correctly, you must avoid to clutter it with technical stuff at all costs. So, that means you have to extract the cross-cutting concern ( Security, Caching, … See AspectJ) out of your code, and apply it globally using Aspects.
Validation can be seen as a cross-cutting concern that is tightly coupled with the domain logic : Validation IS business logic, but it also IS spanned everywhere in the code, at every tier : First you check the constraints using Struts2/Spring MVC built-in mechanism (Annotation, XML..), then you pass it to your business layer which does additional checks, which then passes it to the Data Access Layer (DAOs..), which also has its set of constraints (which can evolve, with time, into something that is not compatible with the constraints checked at the View/Controller level. And this doesn’t take into consideration complex applications where additional batches or gateways are created, where duplicating the validation code is the rule, not the exception.

Currently, if you do not want to duplicate the validation logic, you have to :

Either throw exceptions at the data access level (what do you do for objects that are not persisted ?) and catch these exceptions in the view. Then manually handle the exceptions to display error messages. In other words: bye bye struts2 validation framework, that does everything for you.
Either place the validation logic somewhere in the domain, and “hope” the miscellaneous developers of the various tiers will call the validation logic. If they don’t, then nothing will get validated

What would happen if such a JSR were to be implemented in all major products (Hibernate, Struts2, GWT, whatever else …) :

You would write your domain logic as usual (i.e. using DDD)
You would write your cross-cutting technical concerns as Aspects
You would use a set of standardized Java5 Annotations to specify the validation rules on the Domain Objects, as well as write a set of custom Annotations if you need more than that.
The bottom line: everything would be magically checked at every level of the application : The view technology (struts2, spring mvc) would display nicely formatted error messages without even submitting the form (AJAX…), the data access layer would throw exceptions if the constraints are not fulfilled, and the developers wouldn’t need to care about validation anymore.

The good news is that validation is now believed to belong to the domain thanks to ruby on rails ?), so this kind of design should soon be possible..

Permalink Comments

Sami Dalouche

06.02.07

Validation Framework Consolidation : where are we ?

Pages

Archives

Categories

Search

Meta