1 session for the life of an application is a very bad idea. that would make the session a singleton, which it's not designed for. the session factory is (should be) a singleton, sessions are cheap and can be created/disposed as necessary.
a session != a database connection. a session can use multiple connections, all handled by the internal workings. I develop web application and system services using a message bus. These contexts have very definitive boundaries for a unit of work. Rich clients isn't as clean cut. I have seen 2 approaches: Conversation per Business Transaction and session per form. Ayende wrote an MSDN article on this not too long ago (http://msdn.microsoft.com/en-us/ magazine/ee819139.aspx). NH, the session specifically, is more than just a way to write sql/ execute sql statements. it's a unit of work, an identity map, change tracking, proxy management. NH add-ons also tie into the session/ transactions (full text searching, caching, validation, etc.) I would recommend utilizing the current session context. this allows you to inject the current session into components as necessary. example //begin a unit of work if(CurrentSessionContext.HasBind(factory) == false) { CurrentSessionContext.Bind(factory.OpenSession()); } //within the unit of work var session = factory.GetCurrentSession(); //complete a unit of work if(CurrentSessionContext.HasBind(factory)) { CurrentSessionContext.Unbind(factory).Dispose(); } if one of the built in contexts doesn't fit your need you can implement ICurrentSessionContext and use that instead. one approach that has served me well is the use of DTOs to communicate outside the scope of the session. Context specific DTOs means more code/objects. the benefit is an object serves exactly 1 purpose, is dead simple, and very explicit. This may be worth considering, instead of shuffling the entity around outside the scope of the unit of work. On Sep 15, 3:01 pm, José F. Romaniello <[email protected]> wrote: > Session per use case is a good pattern for desktops applications. Read > Fabio's post about Conversation per Business Transaction. > We have an infrastructure in unhaddins and some samples WPF/Winforms. > > 2010/9/15 PLen <[email protected]> > > > > > Fabio, > > > I am laughing as I am typing this. I went out to find some info on > > the session-per-application "pattern" and found some things like > >http://techiethings.blogspot.com/2010/04/nhibernate-session-managemen... > > . > > But from reading your response I am not sure if you are saying that > > session-per-application, aka TIME BOMB session management, will end up > > blowing your application up if you use it. > > > Is that what your thought is? > > > Thanks - Peter > > > -- > > You received this message because you are subscribed to the Google Groups > > "nhusers" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<nhusers%[email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/nhusers?hl=en. -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
