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].
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en.

Reply via email to