I believe there is no way to have NHibernate automatically reconnect on lazy load of a collection today. I know this is a feature of Hibernate 3 and I was wondering when it was going to be implemented in NHibernate. As far as I can see NHibernate is not very practical to use in smart clients without this feature. I hope I'm missing something. Does anyone have a solution to this problem for Windows Forms apps that cannot hold an open connection but need lazy loading?

Thanks

Yes, there are several others who would really like this feature. Apparently there is a potential problem since the reconnect/load/disconnect occurs in a different transaction, but for people who don't care (i.e. those who don't need everything selected to be from the same point-in-time), it should be available. I agree, Windows Forms applications are screwed without this feature ...

I'm not familiar with how it's done in Hibernate 3. Does it do the reconnect/load/disconnect for you, or does the interceptor simply expose methods like OnLazyLoading() and OnLadyLoaded() and let you control it?

I disagree. You should be smart about what you select.

That said, you could maybe create your own ISession implementation and let it go to the server before delegating the request to a real ISession.

I'm not sure what you mean about " being smart" when selecting, but our reality is that we must develop applications that are then given to our custom services department. They can hack up the application any way they wish, but prefer to incrementally add logic in various event handlers. Our customers, who are not tech-savvy, can do the same, sometimes even adding a 3rd layer of customization on top of what our custom services did.

Maybe I'm really confused, but I don't see how we can "be smart" and select "just what is needed" to avoid lazy loading, when we write base application code. Now that we expose entities, anyone at a later time can try to access some uninitialized lazy-loading property in some event handler.

I agree. The power of lazy loading is that it ensures that the OO abstraction is maintained regardless of how a client object plays with our business objects. After all, if a client object has to have knowledge of where the object graph ends we really aren't getting much benefit out of our abstraction are we?

Absolutely, this can lead to N+1 query issues. However I believe it is totally reasonable to get an application up and running first and then look at how data access can be optimized for certain use cases based on analyzing usage patterns. Not that it's very easy to tune our queries given the fact that NHibernate does not give us the flexibility to selectively eagerly load collections in different use cases. Incidentally, this is something I've never understood. Why can't we pass an argument indicating which child collections are eagerly loaded and have the rest default to lazy loading. It seems terribly inflexible to have to write in stone which collections are eagerly loaded and which are lazily loaded. I know that DLINQ includes such an option (The "Including" function). Why was the decision made to fix these relationships in NHibernate. I'm sure there's a reason for it, I just don't know what it is.

In terms of being smart about selects there are many cases where it's not possible to know apriori whether a child collection will be needed or not. In fact, I would say this is very common for applications which are navigated in a heirarchical fashion - I want to look at all the customers. Now I want to see all the customers orders (or not). Now I want to see the products in a particular order (or not) - and so on...

Incidentally TheShark your comment about wrapping the Session intrigues me. I'm attempting to do just that to accomodate an N-level cache (as well as reconnecting when lazy loading). Do you have any experience doing so? It's a big interface and wrapping it is non-trivial. I'ts a bit overwhelming and I'm wondering if anyone out there has already done it.

Nels, I didn't mean to offend you. Apparently, you really need this. I don't reference nhibernate on my client, so I don't have proxies on the client that will try to lazy load stuff as soon as somebody touches the property. They will just get a null exception (well, not, because I do initialize them).

So, then, here is a possibility of building something a lot of ppl want.
Jhusian: please take a look at the castle project. Hammet has created a nice nhibernate facility that has a class in it that delegates to a real session. I have not spent enough time there to give any real pointers, but I think the opportunity is this:
Implement the ISession interface, but every method just delegates to a real session. Implement the notion of 'being connected'. Check if you are connected or not, and if not, open an 'inner session' and then delegate the call to that session.

Actually, when I think about it, it might not even be too hard. However, I can't really say, because I'm trying to avoid proxying my classes and only lazy loading collections.

There is a class SessionDelegate in the NHibernateIntegration facility of the Castle project. It aggregates a NHib session and delegates all the calls to it. I am not sure but check out the code to see if it is useful for you.