What is your session management strategy for NHibernate in desktop applications?

Question

I find it much more difficult to manage your session in a desktop application, because you cannot take advantage of such a clear bondary like HttpContext. So how do you manage your session lifetime to take advantage of lazy loading but without having one session open for the entire application?

Paleoasiatic

Answer 1

I think it boils down to the design of your objects. Because lazy-loading can be enforced in the per-object level, you can take advantage of that fact when you think about session management.

For example, I have a bunch of objects which are data-rich and lazy loaded, and I have a grid/summary view, and a details view for them. In the grid-summary view, I do not use the lazy-loaded version of the object. I use a surrogate object to present that data, and that surrogate object is not lazy loaded.

On the other hand, once a user selects that record for viewing/editing, and you enter a multi-paged details view of the object, that's when we apply lazy-loading to the specific object. Data is now lazy loaded depending on which details are viewed only on demand. That way, the scope of my session being open for lazy loading only lasts as long as the details view is being used.

Exponential

Answer 2

Ayende has recently written a great article on the subject in MSDN.

Charily

Answer 3

As you said before, you cannot use the boundary of the HttpRequest, but you can understand what is a "HttpRequest" in your desktop application.

Let me explain. Usually your HttpRequest will be a controller for an action and you will limit your session to that specific action. Now in your desktop application the "controllers" (events) can be smaller, but as @Jon said, a window can easily represent a boundary: you work with the things there, let them be on your session.

Pelson

Answer 4

Maybe we can think of a Command pattern set up. Each significative event will feed and trigger a Command, and Execute it. The base AbstractCommand.Execute() implementation is in charge of initializing the session, wrapping the transaction, calling the concrete SomeCommand._Execute() implementation and closing all the stuff.

Anyway, this is far from being persistence agnostic, as it should be when I have loaded my object and I (want to) deal just with plain instances (I'm expecially referring to lazy-load here).

Is it otherwise possible to implement some sort of auto-open/auto-close behaviour? This should be accomplished by making persistence layer sensitive to needs for queries by higher layers, even in the implicit cases such as lazy-load triggers. As for closing the connection, the persistence layer might close after a given timeout (10 seconds?) of DB inactivity. I know, this is not sharp. But it would really make higher layers persistence agnostic.

Thanks, Marcello

Keenakeenan