Is it a good practice to avoid using Session State in ASP.NET MVC? If yes, why and how?

Question

It\'s not explicitly written somewhere but I felt so after reading few blogs on ASP.NET MVC. Just got curious and thought of asking it here.

UPDATE:

Answer 1

What would it mean to avoid using Session State for you? Do you need to conveniently store small amounts of user data across requests? If so, how else would you do it?

I'm not sure what your alternatives to Session State would be. Using Session State as it exists, out of the box, in ASP.NET is far more desirable to rolling your own alternative, especially from a security perspective.

Answer 2

In ASP.NET Web Forms, passing information between different pages was never especially easy without the use of session. Due to the postback-centric model, information was available on the server as part of an event, but often in the wrong page for displaying a result, making passing information between pages necessary.

This tended to lead to an overuse of session, populating "current" variables in session intended to indicate what the current object being interacted with was. This overuse in turn made applications very state-dependent and much harder to determine expected behaviour ("Is this variable populated?" "Do I have the current order ID yet?").

MVC is structured around the idea that your website is a view into a logical model of information. It encourages having stateless operations through the use of simple controllers responding to actions with key information passed as part of the HTTP request.

Because of these properties, session is no longer required to perform basic tasks in MVC, and becomes poor fit where it has seemed a perfectly valid choice before.

---

Fundamentally, session pollutes HTTP. It makes requests (often containing their own state) dependent on the internal state of the receiving server. This is why it's seen as something of an evil (although often a practical and necessary one).

Answer 3

Session expiration usually doesn't correspond to user's intention (e.g, if IIS recycles, your inproc session state is lost). The only thing I think it may be useful for is user data caching, and not the authoritative source of truth (which most probably should be DB).

Answer 4

It really depends on how much data you are maintaining in the session state. As a rule of thumb, I try to just use it for a few strings here and there and not much more. For a large form, for example, I might store a reference ID to that session, then store all the needed data in SQL temp tables based on that ID. It is kind of a pain, but the session state is not meant to be used to store loads of information.

Answer 5

Use TempData instead of HttpSessionState. TempData is Mvc's wrapper of Session state.

Answer 6

Adding to previous answers

Session are usually evil in terms of modern application and modern application here applies mostly to cloud-centric applications but hugely depends on where we store them.

Regardless of ASP.NET WebForms or ASP.NET MVC, usually with session, we imagine a shopping cart with cart filled or removed which is maintained throughout how actually session is maintained. So this was easy and cheap way of doing things, usually session resides on

1. InProc
2. StateServer
3. SQLServer
4. Now on distributed cache more details

HTTP by birth is stateless, so when we want to horizontally scale up application we add nodes to web-tier or other tiers, so now problem is which node will serve current user's request? it hugely depends on load-balancer which has different modes of doing balancing.

So multiple nodes can serve request for same user depending on loadbalancer but we can kind of override with sticky session in web-tier which will ensure current user will use same nodes, that fails when scaling up application, classic example consider we have 1,000 active session on each 2 node and now we add one more node, we generally expect 3 nodes share near equal number of session however that fails coz those 1,000 must be active in particular nodes cause we are using sticky session, scaling will take time till those session are cleared.

Again what if we want to scale up or reverse scale application? or one or more server goes down, whole session data will be lost if we keep session on InProc or StateServer and even when web-tier nodes switches for same user, whereas if we store on SQLServer its fine but usually slow, so the answer here seems to be distributed cache which is fast and can be made reliable.