[b]Hibernate version: 3.0b4

I've read the book and reviewed the forums, but I'm still having problems deciding on the best approach for dealing with references between domain objects.

I don't feel comfortable with the session in view pattern -- I feel like database sessions should be kept for a minimal amount of time, isolated to a specific layer.

Given that, I feel I have a couple of options:

A) Return graphs of domain objects, where all lazy references are initialized; probably okay for use cases with small graphs, but not ideal in situations with larger graphs..

B) Return graphs of domain objects, where lazy references that aren't needed by a use case are left as lazy collections. Dereferencing these will cause exceptions, so this puts the onus on the caller to know what is / isn't initialized (could use wasInitialized(), or simply avoid the fields).

C) Return graphs of dtos / or copies of the domain objects, where unitialized refs are null.

D) Fully initialize small graphs, and use report queries for larger use cases (e.g.:don't return graphs in larger cases -- just return a collection where each row contains just the fields that are needed)

Am I leaving any options out? What method has worked best for you?

Thanks

G

Session in view pattern has worked best for us. As for your misgivings, you may try thinking of it differently. The session control does not live "in" the business, presentation, or persistence layer. It demarcates when the user-transaction begins and ends, and thus of necessity cuts across all layers. For web apps this is perfect, since the request-response cycle defines the transaction well, and this cycle hardly exists in any single layer.

DTOs have been called in some places "False Decoupling", as instead of hiding the code in the layers, you duplicate it.

Think about what is simplest. I find an interceptor controlling the session simple for me: all code in one place, and the layers need not concern themselves with it. The other options you list seem more complicated to me, DTOs most of all.

Just my 2 cents. The wiki has a good discussion of this.

+1
open session in view is a great an easy to implement pattern.
Just use the servletFilter and it will be verry easy.
The session (and underlying jdbc connection) will only be opened a short time (httpRequest cycle).
This the best approach to have a transparent loading when lazy associations are fetched in the higher layers.

Thanks for the feedback. I've seen the positive feedback about the session in view pattern, and I can definitely see how it would make things easier.

The thing I haven't seen a lot of discussion about is the potential negatives of extending the session for a longer period. E.g.: the best practice I've heard in general is to keep both connections, and in particular transactions, open for the smallest period of time possible. Session in view goes against this, which is why I'm searching to determine what opinions others have come up with on this issue.

not really, 1 httprequest cycle is short...

The long session per application transaction let the session alive (not opened since it is disconnected/reconnected at each httprequest) during a longer period.

It is different, it allows you to avoid a lot of detachment/re attachement but the session grows in size which can be bad if you do failover.

There is no ultimate pattern for session management, you have to choose which one is the best for you.

If yours is a web application, than request cycle is the shortest viable period if you have lazy associations that may need to be filled in the view. The session should be open until all needs of that transaction have been filled, which means once view is rendered.
If you have the view make a new request in a new session, you will lose the benefits of the session-cache, which are significant.
Many many people are using this pattern with great success. Don't throw it away on theoretical grounds: produce a simple prototype and test it. We're engineers, after all!
That being said, your needs may be different.