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 se

Answer 1

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

Answer 2

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. (Edit In MVC 2+, it lasts until it is next read.) 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 3

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 4

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.