Class-level constraints
Some of you have expressed concerns
about the ability to apply a
constraint spanning multiple
properties, or to express constraint
which depend on several properties.
The classical example is address
validation. Addresses have intricate
rules:
a street name is somewhat standard and must certainly have a length limit
the zip code structure entirely depends on the country
the city can often be correlated to a zipcode and some error checking can
be done (provided that a validation
service is accessible)
because of these interdependencies a simple property level constraint does
to fit the bill
The solution offered by the Bean
Validation specification is two-fold:
it offers the ability to force a set of constraints to be applied before an
other set of constraints through the
use of groups and group sequences.
This subject will be covered in the
next blog entry
it allows to define class level constraints
Class level constraints are regular
constraints (annotation /
implementation duo) which apply on a
class rather than a property. Said
differently, class-level constraints
receive the object instance (rather
than the property value) in isValid.
06000
The advanced address validation rules
have been left out of the address
object and implemented by
MultiCountryAddressValidator. By
accessing the object instance, class
level constraints have a lot of
flexibility and can validate multiple
correlated properties. Note that
ordering is left out of the equation
here, we will come back to it in the
next post.
The expert group has discussed various multiple properties support approaches: we think the class level constraint approach provides both enough simplicity and flexibility compared to other property level approaches involving dependencies. Your feedback is welcome.