The PathProxy pattern: Persisting complex associations

PathProxy offers an easier way to persist complex relationships without so many lookup tables

1 2 3 4 5 6 7 Page 7
Page 7 of 7

Adding another entity

I mentioned at the beginning of this article that PathProxy would make adding another entity to our system easy. To prove it, I added a Task entity and its relationship to Developer to the system in just a couple of hours. The PathProxy really helped on the back end, because I had only one class and one table to add.

Besides that, all the work is in the UI: addTask.jsp, developerDetail.jsp, adding a facet to the index.jsp tree, and backing bean stuff: adding the TaskBean, adding a couple methods to PersonBean, and adding the node handling for Task to AjaxTreeBean.

The PathProxy itself did not change at all. The UI and backing bean code would have to happen regardless of how the relationship were maintained. It is simpler with the PathProxy in place, however. You don't have to add a class and table for the relationship, and there's less churn in the changes made to the backing bean code because it relies on the same PathProxy logic, and doesn't have to deal with a new class.

Seeing everything that doesn't have to be done to add in the Task class is great confirmation that the PathProxy pattern keeps the domain model and persistence layer stable -- what a relief!

In conclusion

The key benefits to the PathProxy pattern are consistency and extensibility. PathProxy's enforced consistency greatly simplifies the overall system design. Its extensibility makes a routine of adding more relationships, even ones with extremely complicated pathing. Just build the path and hand it off to the PathProxy. You can do that as many times as you need to without changing the database schema or adding any more classes.

Like most design patterns, the PathProxy really needs to be justified in its usage, otherwise you risk over-complexity. Also like other design patterns, if your situation calls for it, it is exactly what you need and can provide a major foundation to your system, becoming an architectural principle as well as a design pattern.

I hope you will use the PathProxy pattern for those situations where it is just what you need.

Learn more about this topic

  • Download the sample application for this article, built with Spring, JPA/Hibernate, and JSF. The application build tool was Maven 2 and it was tested on Tomcat 6.
  • PathProxy isn't Matt Tyson's first published design pattern. Learn about his design strategies for Ajax-style development in JavaServer Faces: the AjaxCommand strategy and the AjaxComponent strategy, both published by JavaWorld.
  • The Spring Framework Documentation Section 3.3.4.1 explains Spring's lookup method injection.
  • See the JPOX homepage for a good discussion of JPA inheritance.
  • "Understanding the Java Persistence API" (Aditi Das, JavaWorld, January 2008) is a two-part introduction to Java-platform persistence with JPA. Part 2 walks through an example implementation of JPA annotations.
  • "J2EE design decisions" (Chris Richardson, JavaWorld, January 2006) explores five design patterns for implementing enterprise applications using lightweight frameworks such as Spring and Hibernate. An excerp from POJOs in Action; Manning Publications, January 2006.
  • "Get started with Hibernate" (Christian Bauer and Gavin King, JavaWorld, October 2004) is a short introduction to Hibernate written by its creator, Gavin King. Excerpted from Hibernate in Action; Manning 2004.)
  • Visit the JavaWorld Java Standard Edition research center for more articles about core Java programming tools, design patterns, and concepts.
  • Also see Network World's IT Buyer's Guides: Side-by-side comparison of hundreds of products in over 70 categories.

This story, "The PathProxy pattern: Persisting complex associations" was originally published by JavaWorld.

Copyright © 2008 IDG Communications, Inc.

1 2 3 4 5 6 7 Page 7
Page 7 of 7