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!