Hi!
Today I was reading: Why can't Hibernate just load objects on demand?


I find some of its affirmations interesting (I realize this is kind of a sensitive topic, but I just dont feel that the information there is not convincing enough, specially if you have used other ORMs that do have distributed non-transactional lazy loading and I really would like to understand this more (what was the big desing flaw that I missed when working with other ORMS?) (I would also like to state that NHibernate is one of the best ORMs I have used... IMO it is the closest thing to a perfect ORM... if it only had automatic transaction management an non-transactional lazy loading...):



That really is a very good question, what exactly it is so good about having transaction demarcation? (wouldn't it be better to have "automatic transactional demarcation"? like this:



Wouldnt it be better, if, as we have the Session, and the transactions...we could have an equivalent to ECO's EcoSpace?

(Important Note: I am NOT saying ECO is better than NHibernate, if fact I had to choose between the two for a project, and IMO NHibernate was a better choice, because its mapping capabilities for legacy databases are far superior, and its lower level session/transaction base API gave me more control, and HQL is IMO more powerful than OCL... but not all projects need that level of control, and... specially for new projects that do not need to interoperate with legacy apps, or that will have full control of the database ECO could be a much better alternative because of its easier to use API with automatic transactional demarcation and non-transactional lazy loading)




I guess in that case it should throw an exception... but I don't see this a justification for transaction demarcation... IMHO the same problem can happen with regular "manual session opening an closing"



Yes, but that also means I need to have a session and transaction open during user think time...



That is really a problematic question... in fact... the question is my point exactly... why should I bother having a service layer if every object can be retrieved by simply navigating to it? IMHO not having to have a service layer sounds like a good thing... doesn't it?




So... that means... that if we want distributed non-transactional lazy loading we should build a streaming objects from some persistent data store in undefined units of work service? is that what other ORMs (like Borland ECO or Apple's EOF) are? who draws the line? I know that the owners of Hibernate are free to choose, but is this decision theoretically supported? I'd like to know how...)




Yes, but OpenSessionInView is only a good idea if you are building a webapplication.. and if you want only one transaction per request/response cycle... if you UI deviates from that... then it is no longer such a good idea...




Well, then, why OpenSessionInView isnt a good idea for interactive UIs in smartclients? isn't changing form ASP.NET to WindowsForms a change on the presentation layer? so.. If i built my application to share its bussines logic between a WindowsForms and an ASP.NET presentation and I am going to have problems... then that means I am tied to a particular presentation layer... isn't it? (Maybe OpenSessionInView should be renamed to OpenSessionInWebView...)

Note: Some people still believe that this pattern creates a dependency between the presentation layer and Hibernate. It does not...

You might want to have a look at Dependency injection.

Hi Luxspes, you make some interesting points and have given me some food for thought. To this point in time, I have simply accepted the standard answer to "Why can't Hibernate just load objects on demand?" purely on a matter of faith. I trust that Gavin and Christian have way more experience than me and they know what they are talking about.

However, I wish that someone would support that answer with specific real-life examples of exactly what could go wrong with loading objects on demand.



Luxspes, your guess is the same as mine. That is, I think the lazy load should be automatically attempted and an exception should be thrown if the owning entity has been deleted. I don't understand why this would be a problem.



We are using Hibernate in a two-tier HMVC rich client and I have been wondering whether the OpenSessionInView pattern could be adapted to a rich client. Indeed, I think there are some similarities to OpenSessionInView in Christian's Hibernate and Swing demo app. I do think he is onto something with that demo. I think the idea of assigning sessions to HMVC triads (optionally passed on to child triads) could prove to be useful to us.

I think the trick might be in differentiating between: 1) use cases that need long sessions to allow for multiple steps and/or user "think time" and 2) use cases that are short and similar to the request-response model of most interactions in web apps. Our app seems to have both types of use cases. The OpenSessionInView pattern article discusses both the short session and long session variations of the pattern. I think Christian's swing demo framework code could be adapted to support both types of sessions in the same app.

Perhaps someone who is smarter and more articulate than me will some day distill these ideas into a "Open Session in Rich Client View" pattern?