Java Validation With Dynamic Proxies

By Eric Olson
2005-05-14


Loosely coupled validation
You can get around tight coupling by having the interface implementation call a separate service to perform its validation logic . Typically, this service will have a set of validation rules assigned to specific methods on specific objects. Because the validation rules are decoupled from the interface's business logic, they can be reused across many methods on many objects. You can also define the validation rules externally, in which case changing the validation logic will be a matter of changing the validation service's configuration.

Listing 3 shows how a validation service can be used to decouple validation logic from the implementation's core business logic.

Listing 3. Using a validation service

public void setPassword(String password) throws ValidationException {

    BusinessObjectValidationService.validate(this, "setPassword", 

                                             new Object[] {password});



    this.password = password;

}

Here, the validation logic is run as part of a service external to the object that is calling it. Specifically, validation performed on the setPassword() method is configured to a validation service rather than in the method itself. This type of loose coupling can, in many cases, address the weaknesses in the previous example:

* Validation rules are potentially reusable as they may be written once and defined to many methods on different objects. For instance, I could write a validation rule asserting that a given parameter was not null and then reuse it across all methods needing the same rule.

* Validation rules are potentially configurable. For example, I could initialize the validation service with an XML document describing the rules to run for specific methods and objects. I could also expose an API into this configuration, which would let me change validation rules at runtime.

Although a step in the right direction, this approach still has some drawbacks. When I developed the method, I had to be sure to call the validation service and ensure that the method implementation declared its ValidationException. These are artifacts of the validation service that don't have anything to do with the core logic of the method. What I really want is a way to write the User interface implementation so that it doesn't need to know these sorts of things.

What about code generation tools?
Developers sometimes use code generation tools to insert boilerplate validation code into business methods. Like the dynamic proxy approach, code generation tools let you write your implementation code free of validation concerns. The difference between the two approaches is that, unlike dynamic proxies, generated code is always present in business objects and cannot be switched out with another implementation, such as an invocation handler. Using dynamic proxies allows you to change invocation handlers at runtime without recompiling the code or redeploying the application.

Tutorial Pages:
» Decouple validation processes from your business object implementations
» Tightly coupled validation
» Loosely coupled validation
» The dynamic proxy approach
» The invocation handler
» The business object implementation
» The business object factory
» Drawbacks of dynamic proxies
» Other uses for dynamic proxies
» Conclusion
» Resources


First published by

 |

Related Tutorials: » All about JAXP, Part 1 » Make Database Queries Without the Database » Load List Values for Improved Efficiency » 2 Ways To Implement Session Tracking » A Simple Way to Read an XML File in Java » Develop Aspect-Oriented Java Applications with Eclipse and AJDT