i'm not talking about re-attaching an entity to the session i'm talking about intercepting the lazy initiation so that the container entity could save some info on the collection
i really see it fitting well in IInterceptor On Fri, Mar 5, 2010 at 8:55 PM, Fabio Maulo <[email protected]> wrote: > The answer is "Presentation Model" and not put a full filled NH's session > somewhere. > > 2010/3/5 nadav s <[email protected]> > >> i actually faced a similar problem where i needed to do something whenever >> a collection is loaded. unfortunately i couldn't find any easy way of doing >> so... >> >> i've checked all methods of the NH interceptors and events, and non was >> called back when a lazy load accured. i think that this is something that >> must be added, right there next to on-load-collection, >> on-collection-recreate, etc. >> >> >> On Thu, Mar 4, 2010 at 5:33 PM, Jason Meckley <[email protected]>wrote: >> >>> in the short term getting your entities reattached with GetClone() or >>> Merge() or something like that will have the lowest impact on your >>> current architecture. >>> However, this should only be a short term solution. >>> >>> Anne makes a good point that if you are going to cache your domain >>> entities, NH 2nd level cache would be a better choice. However jumping >>> straight to cache isn't always the best solution. Query optimization >>> can go a long way to reducing database calls and doesn't require any >>> form of caching. I would only use cache (NH or asp.net cache) as a >>> last resort. >>> >>> I would also recommend having a distinct presentation model and domain >>> model. >>> from a conceptual POV you explicitly have all the information you need >>> to understand how the view works. >>> from a technical POV presentation is no long bound to the domain >>> model. >>> The presentation model can then be cached (only as a last resort) and >>> there is no need for cloning domain entities or attaching to session. >>> AutoMapper (on codeplex) makes converting the domain model to >>> presentation model effortless. Ayende has some examples of organizing >>> the presentation model on this blog. >>> >>> On Mar 4, 7:12 am, Gautam <[email protected]> wrote: >>> > We had a similar problem where we wanted to store our objects in >>> > Session and Application variables and ViewState. We also had scenarios >>> > where objects had to be sent across application boundaries via >>> > remoting etc. >>> > >>> > We found that what worked for us is to implement GetClone() for all >>> > our domain objects. >>> > >>> > If a domain object had references to other domain objects, its >>> > GetClone() would in turn call GetClone() for all the referred domain >>> > objects. Though you need to ensure that there are no circular >>> > references. >>> > >>> > //when Saving >>> > Session["SomeVar"] = object.GetClone() >>> > >>> > //When retrieving >>> > object = (Cast)Session["SomeVar"]; >>> > session.Lock(object); //Attach back to session >>> > >>> > Also it helps that Nhibernate Session methods like Save() >>> > automatically attach a detached object back to session. >>> > >>> > all said, I am not sure if this is the best way to go, and would sure >>> > love to hear some better ideas from the community. >>> > >>> > On Mar 4, 1:58 am, hankor <[email protected]> wrote: >>> > >>> > > Hi all, >>> > >>> > > I currently need to refactor a big web application using an ORM >>> > > framework. I would really like to use nhibernate for this & have done >>> > > several tests that show that things would work out well. I have one >>> > > problem left though that is giving me headaches: >>> > >>> > > I want to use one session per request. I will have to use >>> lazy-loading >>> > > a lot. >>> > > The application does at numerous places store things in the asp.net >>> > > session or the asp.net cache. >>> > >>> > > When the application now loads a lazy property for an object that has >>> > > been loaded from there, nhibernate throws - no suprise - a >>> > > lazyinitializationexception. >>> > > I know I have to reattach the item to the session first. >>> > >>> > > BUT, due to the sheer size of the application I can't modify/review >>> > > all places where that happens (which I know in an ideal world I would >>> > > have time to do). >>> > >>> > > So my question is: Is there any way to intercept the lazy-loading and >>> > > check for an existing session previously and reattach if there is >>> > > none? >>> > > For lazily loaded properties I think I could modify the intercept >>> > > method of the generated proxy. >>> > > What would I do for lazily loaded collections (where >>> > > abstractpersistentcollection throws the exception) though? >>> > >>> > > The only thing I could come up with so far is to use a AOP framework >>> > > like postsharp to intercept the calls, but this would be kind of a >>> > > pain too because this would have to be integrated into the general >>> > > build process. >>> > >>> > > Any suggestions for easier ways to solve this? >>> > >>> > > Any help is much appreciated & sorry in case this already is answered >>> > > somewhere that I didn't find. >>> >>> -- >>> 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]<nhusers%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/nhusers?hl=en. >> > > > > -- > Fabio Maulo > > -- > 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.
