Nhibernate/MVC: Dealing with lazy loaded collections in View?

The best way to handle this (in my opinion anyways) is to introduce a service layer in between your UI and your repositories; It should take care of loading everything needed by the view and pass off a flattened (and fully populated) dto to the view.

The best way to handle this (in my opinion anyways) is to introduce a service layer in between your UI and your repositories; It should take care of loading everything needed by the view and pass off a flattened (and fully populated) dto to the view. Often, I go one step further and map the dtos returned from the service layer to view models, which often need to contain data that is very view-specific, and not appropriate for inclusion into the dtos coming from your service layer. Remember, Automapper is your friend when it comes to situations like this.

Using an open-session-in-view pattern is still perfectly acceptable, just don't have your views invoking lazy loading on entity models - this is almost always a horrible idea.

Thanks DanP. I've tried experimenting with Automapper. It looks very promising, however, when I map a collection on my Entity to a the collection on a ViewModel, this still seems to trigger lazy loading (even though the view only has access to the view model).

I can only assume that references to the proxy are being passed in this case. Do you have any advice on how to force Automapper to copy across the real objects from the collection (rather than proxies)? – UpTheCreek Aug 5 '10 at 13:12 @UpTheCreek: simple, use collections of DTOs as well.

Make it a pratice NEVER to send anything mapped in N your actual domain classes) from the service layer. It sounds daunting, but automapper really does make this a snap... – DanP Aug 5 '10 at 13:17 Ah yes, that works a treat, thanks! – UpTheCreek Aug 5 '10 at 13:53 1 +1 Isn't the whole point of open-session-in-view so that you can lazy load from the view?

That's why I never bothered with it. – dotjoe Aug 5 '10 at 14:06 @dotjoe: Partially, but there are other advantages... for example: how about using the first level cache across multiple service layer calls? Batching of inserts/updates/deletes?

There are valid reasons to keep the session open for the entire page lifecycle. – DanP Aug 5 '10 at 14:09.

Consider your current usage as making implicit database operations. The object is sent to the View but the object contains proxies which when touched will try to return the data, and that requires a database operation. Now, extending the ISession life including the View, its not wrong, as long as you are not doing explicit database calls... I wouldn't know about that This is actually the proper way regardless of the session EOL: you should try to do as less queries as possible per request and nhibernate gives you that ability via lazyless loading, futures, multihql/criteria etc.Note: although you may have mapped a collection as not lazy loaded it matters also How you query and get your desired result set.

Eg if you are using HQL then use a fetch join.

Thanks for your answer - the queries that are not eager loading are based on ICriteria, not HQL. – UpTheCreek Aug 5 '10 at 12:05.

I don't think there's anything wrong about the first approach, and it will be the easiest to implement. Session per request is a well known session management pattern for N.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.