Bean validation is a nice API for for validating Java objects and is included in Java EE 6. But it can also be used anywhere, regardless of the layer. It can be used with or without JPA and in a stand alone Java SE.
- It formalizes and encourages the validation approach at the domain model level.
- It helps in de-duplication of the validation logic that we are accustomed to having all over the place - UI, business logic and elsewhere to get it back to the domain model - where it really belongs
In the past, people used (and a lot of them still do) anemic model objects, without ever giving a thought to the fact that they were central to their domain. A lot of validation is central to the domain, but was written elsewhere. I have noticed that people are thinking that the validation (and more) should be brought into the fold of the model objects. Bean Validation could serve as a selling point for Domain Driven Design. It worked for me.
Back to my point - I was desgining a JavaFX application. Not the ones with animation - but regular boring app, but with a horrendous set of validations. Writing all of them in the UI will be such a pain, in addtion to just not being right. Unknown to me, a backend was starting to take shape in another part of the world, where, among other things, validation was implemented as business logic in Spring POJOs wrapped in Session EJBs (you know, the typical hangover from early Spring-J2EE days). There were JUnit tests in place. That emboldened me to offer a refactoring of the validation into the domain classes - which were already JPA entities anyway. Not surprisingly I was met with resistance, but a bit of explanation around Domain Driven Design and the "insurance" of JUnit tests convinced the sponsors they should give it a shot. A few sessions of refactoring (based on guess work) and JUnit regression tests later, the validation logic was sitting pretty in the domain model, with a combination of standard annotations and custom constraints. This impressed the client so much that they started taking an active interest in domain driven design in other part of the system.
With the validations in domain model, I added the domain jar to JavaFX bundling. The required validation libraries from Hibernate were also added. The JavaFX application jar was signed (to allow appropriate JVM permissions for validator). The UI fields were retrieved to-and-from the domain model A Hessian remoting over HTTP allowed the objects to be dispatched to the server. The validations were shared between the JavaFX app and the backend. A happy ending indeed.
Moral of the story:
- You can easily use Bean validation in JavaFX. Don't be scared. It would be a lost opportunity and time if you don't
- You can use Bean Validation to sell the value of Domain Driven Design to your team and managers. It is one of the easy ways to convince - because it is a easy concept to unerstand even for non-technical managers.
Before you jump off and start doing everything with Bean Validation - remember that there are four types of validation
- Data Type validation
- Basic Domain Value Validation - trivial NotNull x less than y etc
- Cross field Domain Validation
- Complex Business Rules Validation crossing mutliple domain objects not in the same object graph
Remember that the first one should be done in the UI. A verification of whether a input is a String or Integer and pasing the int can only be done in the UI. It is better if you customize your input fields to accept only certain keys - thereby effectively eliminating this type of validation. Bean validation is ideally suited for 2 and 3. The fourth type should be evaluated case by case and generally is really business logic that belongs to EJBs or sometimes rule engines
Happy JavaFX'ing with Bean Validation