• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Rob Spoor
  • Devaka Cooray
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Tim Holloway
Bartenders:
  • Jj Roberts
  • Al Hobbs
  • Piet Souris

Handling relationships (between objects)

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I originally posted this in the Intemeadiate JAVA forum, but it was suggested I post this here.
One of the goals in our designs has been separation of data layer, business layer, and presentation layer.
We have Data Access Objects (DAO's) to access data stores (we don't care if the data comes from a relational database, an XML document, flat file, whatever).
Value Objects (VO's) are used to hold the data. Conceptually, they represent a single row from a query and are created and set by DAO's.
Other than the Setters and Getters, the VO's do not contain any business logic, nor do they have any Data access logic in them.
All of this has been presented as back ground into my real question (finally).
Where would (should?) one model relationships between VO's? I think this is really business logic, but could be persuaded (reluctantly) to do this at the VO level.
For example, if you have a sales order. Conceptually, an order consists of header information (Customer ID, shipping info, etc.) and a number of detail rows, one for each item purchased. This is a very basic one to many relationship.
Where is this relationship expressed in code? The sales order could have come from a relational database, an XML document, a flat file, a spreadsheet, etc. Plus we do not want an implementation that relies on a specific data access technology or data source.
One approach would be to embedd a container object in the header VO and then load it with references to the detail VO's, and have a reference on the detail VO's that point to the header.
Another would be to have some sort of relationship object (RO?) that would perform and manage the mapping functions to express the relationship.
There are other approaches that likewise could be used.
I guess I am trying to see how others handle this and what some of the options are. I have not found anything in any of the patterns books that covers this.
Thanks in advance!
 
Marshal
Posts: 16631
278
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here's Sun's example: http://java.sun.com/blueprints/patterns/TransferObject.html
BTW, you may notice they have switched to using Martin Fowler's name for this pattern: Data Transfer Object
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic