Validation services for complex domain objects.

Generally you will write `Validator`s for each of your domain objects, and add a {@link ValidationManager} to your application context. You will need to wire a suitable {@link IntrospectionManager} against the `ValidationManager` so that children of a domain object presented for validation can be identified and in turn also validated.

The {@link ValidationInterceptor} and {@link ValidationAdvisor} should be used against each of your data access object (DAO) mutator methods, such as `SomeDao.create(Object)` and `SomeDao.update(Object)`. The interceptor will cause the `Object` to be presented to the `ValidationManager`, thus ensuring the domain object instance is in a valid state before being persisted.

If you domain objects themselves wish to ensure they are in a valid state prior to internal business methods being invoked, it is suggested they provide a `ValidationManager` collaborator, and fire its validate method. Such collaborator can be autowired during both instance retrieval and creation. It should generally also be marked as `transient`, to avoid possible serialisation issues if used inside a `HttpSession` or similar.

Sometimes domain objects need to internally update themselves before being validated. Any such domain objects should implement {@link BindBeforeValidation}. The `ValidationManager` will fire the related method just prior to validation, and you can do it manually using {@link BindBeforeValidationUtils}. Using the utility class is generally preferred over calling the method directly, as it ignores classes that do not implement `BindBeforeValidation`.

Finally, sometimes `Validator`s might need to perform queries against a persistence or services layer. For example, the `Validator` may be checking no other user has this username. If using an ORM tool such as Hibernate, it is recommended your `Validator`s subclass a common abstract parent that provides an `evict(Object)` and `evict(Collection)` method. That way your `Validator`s can utilise standard services layer or DAO methods as required to retrieve other domain objects, and flush them from the session cache afterwards. Whilst this is more a `Validator` design choice than something mandated by this package, we have found it a worthwhile pattern in real-world applications.