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

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.