http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Now that's a really good tip! http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment13http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment13Tue, 12 Apr 2011 14:41:04 GMT+1 for a view model. unless you're app is intended to be a super simple layer over db crud off course. http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment12http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment12Mon, 11 Apr 2011 10:19:18 GMT@Alwin Well spotted, I didn't see that :-) http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment11http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment11Fri, 08 Apr 2011 14:53:15 GMTI'm still up in the air on how I'm going to handle session scope in my next project. It's nice to have it open in view for child actions, but this can lead to many select N+1 in view code if you're too lazy to map a domain object to viewmodel. Child actions are just sooo convenient for a complex site.master menu...so, it really comes down to not being lazy with your view models. http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment10http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment10Fri, 08 Apr 2011 14:31:44 GMTLook at the right, Future Post number 2 :) http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment9http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment9Fri, 08 Apr 2011 14:26:25 GMT@Scooletz Thanks, that makes sense http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment8http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment8Fri, 08 Apr 2011 13:46:31 GMTNot sure I agree with the approach (in fact I don't), there are better ways to solve the Select N + 1 problem, such as strongly typed ViewModels. Plus in real world apps I build, I'm rarely sending just a collection domain models/entities to the View, it usually includes a bunch of other things, hence the argument for ViewModels. http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment7http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment7Fri, 08 Apr 2011 13:45:28 GMT@Adam, Items are held by current request, so as far as I see your point: not, there can be no cross-request problem. http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment6http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment6Fri, 08 Apr 2011 13:28:29 GMTSorry if this sounds thick, but is there a danger of overlapping requests sharing the same session and one disposing a session that is still being used? If that makes sense? http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment5http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment5Fri, 08 Apr 2011 13:20:00 GMT@Ryan, yes, you're right! The child actions are executed when a parent's action result is executed. Your ordering is right. It does not change the fact, that first level cache optimization is lost, and that was the point behind my comment :) http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment4http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment4Fri, 08 Apr 2011 13:09:14 GMT@Scooletz I think each child action creates its own session and disposes it. Also the parent action disposes its own session. Because when child actions are invoked from the view the parent action has already disposed its session. The sequence is like: - parent OnActionExecuting - parent Action - parent OnActionExecuted - viewResult is executed: any child action in the view goes through the same sequence. // Ryan http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment3http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment3Fri, 08 Apr 2011 12:35:20 GMT@François Of course it is not. The scenario goes like: - parent action creates and stores a session in a context - child action creates and overrides parent's session in a context - child action disposes the session - the parent action is left with a handful of nothing, a disposed session. The better solution is to use http modules with Castle disposing module (at the end of a request). It is fired once, at the end of parent request and allows you to use the same session (first level cache). http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment2http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment2Fri, 08 Apr 2011 10:37:45 GMTThis implies we'll have different sessions for child actions. Is this benign? The good point is thanks to the new ASP.Net MVC 3 Global Filters, we won't have to decorate every controller with the NHibernateActionFilterAttribute. http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment1http://ayende.com/4805/refactoring-toward-frictionless-odorless-code-limiting-session-scope#comment1Fri, 08 Apr 2011 09:46:11 GMT