I'd prefer that as well. Anyways, if there's something I regret is these customs lifestyle managers. We should be good with singleton/transient for 99.9% of situations. Well, maybe on Windsor 4...
On Tue, Feb 14, 2012 at 8:23 AM, Jordan <[email protected]> wrote: >> Another approach might be to have a "SessionProvider" or "SessionAccessor" >> that is a factory-like object that provides the session from the container >> by doing a container.Resolve<ISession>(). On the first call for a web >> request, this should create the session, and on later calls, it should >> return the same session already created. Unfortunately, you'll have to >> figure out how to do the container.Release() that goes with the Resolve, or >> else you'll have a memory leak. Hopefully someone else will give some more >> ideas. > > Why not put the ISessionFactory in the container, and then create the > ISession at the start of the web request. Any code that needs access > to the current ISession can call GetCurrentSession() on the session > factory. > > Isn't this pretty much how castle always used to work? > > regards, > Jordan. > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Development List" 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/castle-project-devel?hl=en. > -- Cheers, hammett http://hammett.castleproject.org/ -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" 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/castle-project-devel?hl=en.
