I'm curious to know how others are dealing with this issue:

You want an entity, A, that has associations to B and C. One use case requires that you return just A, another requires you return A w/ Bs, another A w/ Cs.

In the scenarios above, how'd your DAO method(s) look? That is, do you have DAO methods for each use case, like:



or are you passing in some loading level flag:



Currently we have a manageable number of use cases, however, there is anticipated growth scheduled here in the next release. The problem with the second scenario is when we start getting into nested loading levels. Now our aLoadingLevel object gets slightly more complicated. We'd possibly modify this to be a collection of Loading Level objects.

Later on, we decorate our DTO with this same loading level object so that clients won't unknowingly try to load an association that wasn't included in its assembly.

I don't see this best practice addressed anywhere. Is there a best practice out there in the community you'd like to share?

If your logic require flexibility you can atomize your DAO methods:


So you can retrive only what you need case by case and then assemble all in the DTO

We've thought about this in the past, but this flexibility seemingly comes with a performance penalty.

In the two mentioned scenarios we can avoid this via HQL or Criteria API. In an atomic scenario we'd increase our SQL/DB roundtrips.

Why are you doing lazy loading in a DTO? Personally, I'd either use the lazy and deep domain objects retrieved from the datastore and manage sessions up to the presentation layer, or I'd just go with non-lazy DTOs that address specifically what the client code requires.

We're not. Our DTOs are assembled from domain objects that do support Hibernate lazy loading. The issue is how much of the graph to load based on what is initialized in the domain/entity object.

The timeless DTO argument still lives on and I don't want to revisit it here. Our issue is actually mutually exclusive from DTOs. That is, how to deal with different loading levels from DAO. Inidividual methods per use-case, methds which accept a flag object in the signature indicating items to be loaded, atomic methods (which has been suggested)...

What are you doing?[/quote]

IMHO we're talking about the same thing. If you want another option, how about using a DTO factory or Conversions class that transforms lazy/deep domain objects into relatively shallow/non-lazy DTOs, each specific to each use case. That way you can keep your domain objects "pure" (as your desire is indicated by wanting to keep laziness there) while not cluttering up your DAO layer with lots of extra methods.

Scott

We've considered having the DTO factory/assembler do this work. That is, having the DAO return domain objects with all associations proxied/lazy and have the DTO factory/assembler be responsible for loading the appropriate use-case depth for that domain.

This requires that assembly reside inside the transaction. To this point we've tried to adopt a more general assembly strategy: having the assembler load only the graph returned by the DAO. See: http://forum.hibernate.org/viewtopic.php?t=933478.