There is a reason that I like to depend directly on ISession, and make my services transient. It allows me to make assumptions with things like the session cache, uniqueness, etc. With UoW.Current or interceptor approach, that is not the case.
On Mon, Sep 21, 2009 at 11:47 PM, Simone Busoli <[email protected]>wrote: > Thanks Jason, I see it now, and it's an interesting approach, I never used > it though. At the moment I am just doing UoW.Current when I need access to > the UoW, but having a decorator which gives me the current one and still > have it in the constructor is a nice way to accomplish that. > > > On Mon, Sep 21, 2009 at 22:37, Jason Meckley <[email protected]>wrote: > >> >> this is what I like about the SessionAdapter object I posted above. >> you can use the default lifestyle of singleton. the actual session is >> not retrieved (from the current session context) until you call a >> member of session. >> >> On Sep 21, 3:20 pm, Simone Busoli <[email protected]> wrote: >> > I'm not sure I follow you, if I have a component which takes an >> > ISession as a ctor argument, I need to be careful to configure its >> > lifestyle to be "more transient" than that of the session itself, >> > right? Or I'll get an instance of the component with an out of date >> > session. >> > >> > 2009/9/21, Ayende Rahien <[email protected]>: >> > >> > >> > >> > > Simone, >> > > *shrug*, the provide an ISession implementation that will access the >> ambient >> > > session. >> > >> > > On Mon, Sep 21, 2009 at 9:49 PM, Simone Busoli >> > > <[email protected]>wrote: >> > >> > >> That's what I don't like much with this approach, it's easy to do >> > >> something wrong, because you need to be very careful about the >> > >> lifestyle of your components, or you'll get into weird situations. >> > >> Ideally, I wouldn't like my components to be sort of aware of the >> > >> lifestyle of something they depend on, or, put in other words, I'd >> > >> expect them to get the right UoW regardless of whether they are >> > >> transient or singleton. >> > >> > >> 2009/9/21, Ayende Rahien <[email protected]>: >> > >> > yes >> > >> > >> > On Mon, Sep 21, 2009 at 7:20 PM, Martin Nilsson < >> [email protected]> >> > >> wrote: >> > >> > >> >> Yes, that was the case. Thanks. >> > >> >> My other question regarding taking ISession as a ctor argument. >> Then >> > >> >> all >> > >> >> those classes (queryobject, service and repository) needs to be >> > >> transient? >> > >> > >> >> On Sun, Sep 20, 2009 at 12:45 PM, Ayende Rahien < >> [email protected]> >> > >> wrote: >> > >> > >> >>> You need to register the factory facility. >> > >> > >> >>> On Sun, Sep 20, 2009 at 10:15 AM, Martin Nilsson >> > >> >>> <[email protected]>wrote: >> > >> > >> >>>> Ok ok :) >> > >> > >> >>>> I changed to this instead: >> > >> > >> >> Kernel.Register(Component.For<ISession>().LifeStyle.Transient.UsingFactoryMethod(() >> > >> >>>> => Kernel.Resolve<ISessionFactory>().GetCurrentSession())); >> > >> > >> >>>> but then I get error: >> > >> >>>> "Type NHibernate.ISession is abstract. >> > >> >>>> As such, it is not possible to instansiate it as implementation >> of >> > >> >>>> NHibernate.ISession service" >> > >> > >> >>>> My solution now is this (not causing the above error): >> > >> > >> >>>> ServiceClass: >> > >> >>>> ctor(IUnitOfWorkFactory unitOfWorkFactory) >> > >> > >> >>>> In ServiceMethod: >> > >> >>>> var session = unitOfWorkFactory.CurrentSession; >> > >> > >> >>>> Questions: >> > >> >>>> 1. Anyone knows why I get the above error? >> > >> >>>> 2. Is my other solution (using IUnitOfWorkFactory) better/ok >> then? >> > >> >>>> 3. You say that it's possible (better?) to take the ISession as >> a >> > >> >>>> ctor >> > >> >>>> arg. Will that be a different one for each req if my service >> class is >> > >> >>>> singleton, although my session registration is transient? >> > >> > >> >>>> On Fri, Sep 18, 2009 at 9:50 PM, Ayende Rahien < >> [email protected] >> > >> >wrote: >> > >> > >> >>>>> This is HORRIBLE. >> > >> >>>>> You micro manage the session and remove from NH things like >> UoW, >> > >> >>>>> auto >> > >> >>>>> change tracking, persistence by reachability, etc. >> > >> >>>>> Sessions should be managed by request / context, not in >> methods. >> > >> > >> >>>>> On Fri, Sep 18, 2009 at 4:25 PM, Martin Nilsson >> > >> >>>>> <[email protected]>wrote: >> > >> > >> >>>>>> ProductService: >> > >> >>>>>> public void Save(Product product) { >> > >> >>>>>> using(var session = ?.GetSession) >> > >> >>>>>> using(var tx = session.BeginTransaction()) >> > >> >>>>>> { >> > >> >>>>>> repository.Add(product); >> > >> >>>>>> tx.Commit(); >> > >> >>>>>> } >> > >> >>>>>> } >> > >> > >> -- >> > >> Inviato dal mio dispositivo mobile >> > >> > -- >> > Inviato dal mio dispositivo mobile >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" 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/rhino-tools-dev?hl=en -~----------~----~----~----~------~----~------~--~---
