Why would ASP.NET MVC use session state?

Question

Recommended by the ASP.NET team to use cache instead of session, we stopped using session from working with the WebForm model the last few years. So we normally have the session turned off in the web.config

<sessionState mode="Off" />

But, now when I'm testing out a ASP.NET MVC application with this setting it throw an error in class SessionStateTempDataProvider inside the mvc framework, it asked me to turn on session state, I did and it worked. Looking at the source it uses session

Dictionary<string, object> tempDataDictionary = httpContext.Session[TempDataSessionStateKey] as Dictionary<string, object>; // line 20 in SessionStateTempDataProvider.cs

So, why would they use session here? What am I missing?

Thanks,

Ray.

========================================================

Edit Sorry didn't mean for this post to debate on session vs. cache, but rather in the context of the ASP.NET MVC, I was just wondering why session is used here. In this Scott Watermasysk blog post he mentioned on turning off session too as a good practice, so I'm just wondering do I have to turn it on to use MVC from here on?

Answer 1

Hmm... May be you've read about persisting of the heavy objects or relatively rarely accessed objects - it's definitely better to put them into cache, but for light objects or for data that is required at every request there is no better technique than put them into Session.

Sessions are not evil if you are using them correctly.

Answer 2

Recommended by the ASP.NET team to use cache instead of session

@ray247, could you provide a reference for this? Session and Cache are different by nature and should be used depending on application requirements. For example storing user specific data into the cache could lead to undesired behavior. Of course if you really want to avoid using session you could provide your own implementation of the ITempDataProvider interface.

Answer 3

Session is used for the TempData store. TempData is a highly limited form of session state which will last only until the next request from a certain user. The purpose of TempData is to store data, then do a redirect, and have the stored data be available to the action to which you just redirected.

Using Session for the TempData store means that any distributed caching system which already handles Session will work for TempData. Avoiding using Session directly when TempData will do has a couple of advantages. One is that you don't have to clean up the Session yourself; TempData will "expire" on its own.

Answer 4

Just an additional thought. TempData has its own purpose and MS knew there will be different school of thoughts with respect to TempData persistent mechanism. So, by default they made the persistent store to be SessionState. But the design is still very flexible. Based on the needs of the project and the governance that guides it you can create your own tempdata provider to suit specific requirements.

Here are some pointers to the resources TempData

Here are some additional improvements in TempData implementation TempData Improvements

Here's an alternative implementation using MS Velocity Distributed Caching. Velocity TempData Provider