1. In the model (typically as database schema constraints).
2. In the application code.
Both are important. Database constraints allow reuse of the underlying data model in the event that the application code needs to be migrated. Application level validation is able to provide finer grained control (is this a valid email address? is the customer's date of birth in the future?) than can be easily achieved with model level constraints, and can also more readily provide meaningful error messages to the users of the application. Application level validation may in itself reside in multiple places, resulting in a large amount of duplication of effort across the different application tiers. In a typical web application, for example, JavaScript is executed in the browser for simple field level validations and the serverside layer is used for more complex business rule validations. It would be highly desirable to be able to centralize the validation definitions in one place and share the definitions across the different layers.
Led by Hibernate Validator lead developer Emmanuel Bernard, JSR-303 aims to standardize the constraints metadata model for Java EE 6. An early draft of the specification has been released and the expert group are keen to solicit feedback. As part of this a forum has been set up, and Bernard has begun to publish a series of articles (part 1, part 2) on the Hibernate blog describing how the API works.
Unsurprisingly given its parentage, JSR-303 is heavily influenced by the JBoss' Hibernate Validations although a number of the other validator frameworks (Xwork and the Apache Commons Validator for instance) have also influenced the specification. It uses annotations for the majority of cases and provides standard APIs for runtime validation and to query the metadata. Each constraint annotation must define a message of type String which is used to create an error message. Error messages support internationalisation. Constraints may be declared on an object's fields, getters, class, superclass and interfaces and validating an object will validate all of its constraints. For example the following code creates a String called street1 which has a maximum length of fifty characters and is mandatory:
@NotEmpty @Max(50)
private String street1;
The framework is designed to be extensible so that an application can easily define its own additional set of constraints. From the first blog entry:
"A constraint is comprised of:
• an annotation
• a constraint validation implementation
While the annotation expresses the constraint on the domain model, the validation implementation decides whether a given value passes the constraint or not."
As well as supporting instance validation the specification supports validation of an object graph, so for example if a bean ClientDetails contains an Address bean with one or more @Valid annotations the validator will validate the contents of the Address bean when the ClientDetails bean is validated.
One significant difference between the spec and the Hibernate Validator is the concept of groups, which provide a means for creating subsets of validations. Groups have an associated sequence (set via an @GroupSequence annotation) so that a developer can force one set of constraints to pass without error before the next set executes. Groups also allow a partial validation of the JavaBean. The draft specification suggests two scenarios where this might be useful:
"• the second group depends on a stable state to run properlyA number of different pieces of technology in the Java EE 6 platform should be able to take advantage of JSR-303. For example DDL updates when generated via an ORM tool, entity validation on insertion/update by the Java Persistence API, the new WebBeans API, and JavaServerFaces components all look to be obvious candidates.
• the second group is a heavy consumer of time, CPU or memory and should be avoided if possible"