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

Session was avoided even before MVC, because it's info that gets persisted on the server for each of the users that connect to your application and (unlike cache) is not erased automatically when not used.

Also in order to help you avoid using session, ASP.NET had viewstate, which was actually a huge hidden field in your webforms that got POSTed on every postback. This too was too clumsy for various reasons and was dropped with MVC.

So session is actually something that was not very recommended even before MVC. The reason is mostly scalability. The less state you persist, the more scalable your site will be. If you don't care about scalability (for what I know you might be developing an intranet application for 200 users) or if you have very little info to persist by all means do use session. In other cases, using session is entirely appropriate: a typical scenario where session state is used is the shopping cart in a ecommerce site (info which is inherently per-user per-session and that only a percentage of your users actually have populated).

As for the alternatives,there is not a direct, drop-in replacement for session. Depending on what you're trying to do you may be able to use cache or cookies. MVC has not brought anything particularly new in that regard, AFAIK.

Answer 2

Session management was always challenging from ASP.net Web Forms to ASP.net MVC. However, MVC encourages to treate it as Stateless as you have benefit of REST based Web API. Most of the things that we used to store in Session previously accomplished by using both MVC + Web API combination.