What is your session management strategy for NHibe

问题:

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?

回答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.

回答2:

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

回答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.

回答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