PathProxy is a design pattern for persisting complex relationships without cluttering up your database.
When your class relationships require pathing knowledge, that is , knowledge about a number of related objects, then the standard "many - to" associations wont cut it, The PathProxy class is an abstraction of such relationships, allowing you to manage, persist, and extend them without complicating the classes themselves, and without a proliferation of lookup tables.
The fundamental idea is this?: create class that can point to any entity in the system, and that also can reference its own class as a parent, With this class, you create a tree structure that maintains the interrelationships outside of the referenced objects. Building a JPA mapping around this class requires some though, but is quite powerful.
Path-Specific relationships
The PathProxy solution applies in any situation where an entity can appear as an association of another entity type, but only for a specific path. I refer to such relationships as path specific. E is a child of D, but only for the path A-->B-->C-->D-->E.On another path, D might have no children (A-->B-->Q-->D) or might have a different child or children(A-->B-->X-->D-->Z)
As an example, imagine a development team consisting of a project manager named Johnie and two developers, Robert and Mukunda. On project A, Johnie leads Robert and on Project B, Johnie leads Mukunda. This is a somewhat contrived example, but not an uncommon scenario in the world of corporate structures. In the real world, you might have the efficiency of the same process in different business locations, or the actions taken in response to the same event by different teams
When to use PathProxy?
You have many entities whose interrelationships are complex and require knowledge of other relationships. Creating explicit objects to represent these types of? relationships becomes burdensome. This is expecially true if the objects must be persisted, creating a proliferation of database tables.
Consider PathProxy if , Your system design calls for a number of casses whose sole or primary function is to model the relationships between other objects.
Using PathProxy is more complicated than using? simple objects to represent relationships, so consider your particular situation. If you have few relationships to store and they are not too complicated, PathProxy may not be the right choice. On the other hand, once you reach a certain level of relationship complexity, using PathProxy will greatly simplify your overall system design. Beijng able to reuse the same machnaism over and over again is also a huge time-saver.
來自 : http://www.javaworld.com/javaworld/jw-07-2008/jw-07-pathproxy.html?page=1