J1 Session Blog: Bean Validation: Declare Once, Validate Anywhere — A Reality?
Writing validation code might sound trivial but it is far from it. If you ever had to deal with validation in a complex application you probably know that there many requirements. Among them are:
- Easy specification of simple constraints, such as the min and max length of some string property.
- Feasible specification of complex constraints, e.g. validation of an entire object graph with lots of dependencies.
- Factorising the constraints: there is a single place in your entire code where you define the constraint, even if you use it across different layers in your architecture and possibly in different languages.
- Validation should handle both single properties and entire object graphs.
- Flexible creation of validators
- Mapping of validation errors to error messages and error aggregation.
- Defining the order in which validation is executed
- etc.
Emmanuel Bernard, who is the specification lead of JSR 303, did an excellent presentation on Bean Validation. He gave a comprehensive overview, showed a lot of code examples and also dealt with the finer points of validation. I must admit that almost all aspects of validation have been addressed by this JSR. Constraints are defined by means of annotations. There is quite a number of constraints already available and of course one can add new constraints. It is also possible to specifiy the order of validation or partial validation. Error message handling is pretty flexible: internationalization and value expansion are supported among others. The same holds true for validator creation and configuration.
Nevertheless, Bean Validation did not convince me. It is not the lack of functionality but how the code looks like. With complex validation there are so many annotations “decorating” the bean that one can hardly see the bean properties. To me it looks a lot like trying to get programmatic with annotations which are declarative by nature. Moreover, validation annotations are probably not the only annotations attached to a property. There might also be annotations for persistence, transactions etc. The code does not look very readable to me and I am missing the appeal of POJOs. A pure programmatic approach which separates bean and validation might be a better alternative.
