Which layer do I 'hydrate' object graphs?

I have a persistence layer that serves data to many clients. I also have a table structure that is normalized, which means values are spread across tables. I want to design my persistence service to ensure services that depend on it do minimal round trips: not more than one, if possible.

Given this, what should I focus on for an elegant solution?

1. Do I ensure the clients can indicate the portion of the object graph they want during the fetch? (thereby reducing round-trips) [eg: fetch(parent, list<child-object-name>) ]

2. Do I ensure I provide common methods such for hydrating portions of the object, along with basic fetches? [eg: hydrate(parent, list<child-table-name>)]

3. Do I provide basic information to start with (for example, object graph to depth 1 only / only look-up-table objects,) and the rest only upon request?

I understand, there are many many discussion on the net, with very good information. I did read a fe开发者_如何学Cw as well:

* http://forum.springsource.org/archive/index.php/t-23439.html

* How can I access lazy-loaded fields after the session has closed, using hibernate? (answer by Paul Adamson)

* Deep Object Graphs Hibernate

however, most of the answers hover about 'do what suits you best'. What do programmers usually do in this situation?

Don't make a generic one-size fits-all persistence layer. Write persistence methods specifically for the functional use-cases you're implementing.

While doing it, you're probably going to meet cases where a persistence method, or some part of it, can be reused across two or more use-cases. This will probably force you to rename the method to make it more generic (less coupled to one specific use-case), or refactor to extract the common part. But if you want the best performance for your app, you're going to need specific queries for specific use-cases.