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?
Use 'Local Storage 'or 'Session Storage'. Local Storage is not a replacement for Session State.
The basic difference between these two is that the ViewState is to manage state at the client's end, making state management easy for end-user while SessionState manages state at the server's end, making it easy to manage content from this end too. ViewState: It is maintained at only one level that is page-level.
It is perfectly OK to use sessions in ASP.NET MVC, especially in the shopping cart scenario of yours.
The disadvantages of using session state are: - Since data in session state is stored in server memory, it is not advisable to use session state when working with large sum of data. Session state variable stays in memory until you destroy it, so too many variables in the memory effect performance.
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).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With