Hi Matt!
Interesting thoughts, but I'm not sure if JSR-303 is the golden bullet for
business validations. To be honest, I personally doubt it ;)
The thing is there is still the famous old 80:20 rule out there: 80% of the use
cases / processes take 20% of the effort, but the very little rest which is
left (all the 'exceptional' cases) will cost you 80% of the whole budget (money
and time wise).
Why do I do all those prays? Because I personally think that more complex
business validations should still be programmed in the business code because
they are so complex that there is no easy way to 'configure' them. Maybe it can
be done by configuration, but most probably simply coding it will be easier.
It's like with all meta-languages: the more powerful they become, the more
complex they get. And often they grow more complex than having a general
purpose programming language + a few small helper libraries for your special
problem.
Take for example a simple multi field cross - validation. This seems sooo easy
at the first glance, but it is _really_ hard to do it right!
assumption: it should not be possible to set wrong values into your data beans.
This sounds easy, because you just need to validate each field before you
actually set the value. But let's consider a bean (heavily simplified and meta
coded)
public class BeanX {
@MustBeZero if field j > 3
int i;
@MustBeZero if field i > 3
int j;
}
And now what happens if you like to set i=6 and j=8 ?
As you can see, this really depends on the order in which the fields get set.
You can easily set i=6 as long as j is not yet filled. But what happens then?
While trying to set j=8 the 2nd field validation fails. So this situation is
obviously not allowed. But in what state are we now? We already allowed to set
i=6 which is only half of the truth! We basically trashed our bean, because
ideally it should still contain the old values and even setting i=6 should have
been revoked.
I don't think there is a way to work around this without introducing a complete
shadow instance of the bean. But this is only the peak of the iceberg - there
are sooo many other much more difficult situations out there.
To relativate this - I now work with JSR-303 in a EE6 project since december
last year (being a really early adaptor) - and in those 80% of the cases
JSR-303 eases my life HEAVILY. I'd say the rate is even much higher - close to
98% (*). But there are still those 2% where I rather code my business rules in
Java than I configure an utterly complex JSR-303 ruleset.
So while having a dynamic ruleset seems cool from the first glance, I'm not
sure if the old-fashioned way of just coding it wouldn't be much easier?
LieGrue,
strub
(*): to make this more clear: JSR-303 really rocks, because you will get rid of
manually hacking most of the 'dumb' validation code which is always the same
over and over again...
----- Original Message ----
> From: Matt Benson <[email protected]>
> To: [email protected]
> Sent: Thu, June 24, 2010 8:47:25 PM
> Subject: Dynamically applied constraints
>
> Hello all--
I'm just getting my feet wet with JSR-303. I started
> out using hibernate-validator, but as a foundation member and general
> connoisseur of Apache Kool-Aid I thought the very least I could do is give
> bval
> a fair shake. So far, just browsing code and javadocs--my typical way of
> acquainting myself with an OSS project--I'm impressed, FWIW.
What I want
> to do is expose all my validation information to my controller/view layers
> per
> the standard APIs, and here's the catch: *including* business-level
> validations which can be extremely dynamic in nature. To be more explicit,
> I am in the insurance industry, which (in the US anyway) consists pretty much
> entirely of "special cases."
Firstly, is this considered out of scope of
> "Bean Validation" (the spec)? bval? If so, why?--It's my feeling
> that the spec intends that "validation" be quite an open-ended concept. A
> blanket "don't do this" would simply make me question the overall usefulness
> of
> the spec. However, it's obvious (at least, I *think* it is) that neither
> the annotation-based nor XML-based configuration methods can handle the
> dynamic
> application of constraints to a model. At the same time I want to be able
> to use those configuration methods for the subset of validations that *can*
> be
> handled so globally.
I am thinking that I can reuse some of the
> underlying APIs from one of the existing Bean Validation implementations to
> maintain this dynamic information, then implement the ConstraintValidator for
> an
> e.g. @DynamicValidation annotation to reuse others' machinery.
> *This* I could configure in XML; best of both worlds. So to put this into
> bval terms, I could maintain a MetaBean graph for each distinct model graph
> and
> dynamically apply constraints per graph.
This email has written itself in
> the sense that writing down my thoughts led to numerous edits and sculpted
> the
> above-outlined approach, which I'm tentatively feeling pretty good about, but
> I'd still like to get preliminary feedback from the community on the oh-shit
> level of the task I'm setting myself.
Regards,
Matt
