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:
I'm not asking about memory/storage/RAM concerns on server. For them, there is a solution to store session out of process. I know that. I'm curious that, are there any scenarios where we had to use Session in WebForms but we can avoid it now in MVC taking benefit of the nice structured way offered by MVC?
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).
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.
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.
Use TempData instead of HttpSessionState. TempData is Mvc's wrapper of Session state.
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
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.
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).
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.
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.
