Helping ordinary people create extraordinary websites!
| |
Helping ordinary people create extraordinary websites! |
Java Validation With Dynamic ProxiesBy Eric Olson2005-05-14 
Other uses for dynamic proxies
Dynamic proxy classes have many uses within a business object framework other than simply validating methods in a uniform way. The simple invocation handler I built could be used for any pre- and post-method invocation processing. For example, I could easily take business method timings by inserting code before and after the business object implementation method calls to measure elapsed time. I could also notify interested listeners about state changes by inserting some post-method invocation logic. Using beans for validation In addition to the approach discussed in this article, you can use the constrained properties facility of the JavaBeans architecture for validation. In a nutshell, before a constrained property is changed, any number of interested listeners are notified. If any of the listeners do not approve of the change, it may throw a java.beans.PropertyVetoException exception, which signals that the property change is not acceptable. This model actually works well with dynamic proxy classes because the entire messaging mechanism can be built into the invocation handler. As with the approach described in this article, the real business object implementation does not need to know or care what type of validation is being done. In fact this sort of validation could be introduced later without changing any of the method implementations involved with a constrained property. In the example, I created the dynamic proxy class for a single interface: User. I could just as easily specify multiple interfaces that the dynamic proxy class would implement at runtime. In this way, the object returned from the static factory method could implement any number of interfaces defined when I create the proxy. The invocation handler class must know how to deal with method invocations of all the interface types. You should also notice in the example that I always call an actual implementation class to perform the business logic. This does not have to be the case. For example, the proxy class could delegate the method invocation to any other object or even handle it itself. A simple example of this is that I have an interface that exposes a number of JavaBeans properties via set/get methods. I also create a specialized invocation handler that holds on to a Map where the key is the property name, and the value is the value of the property. On a get call, I simply return the value from the Map; on a set call, I replace the value held in the Map, alleviating need to write code for these simple JavaBean class implementations. 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
|
 |