Session in ASP.NET MVC applications
Date posted: 20/11/2016
You haven't filled in compulsory values.
The email is not correct
Session is a simple and nice way to store info in memory and has been used in ASP.NET for a long time. Since MVC came out, there were many people out there saying that session should be abandoned and replaced by other methods while others said that there is no problem using session the way we used to. As this may confuse developers that are not highly experienced in MVC, let's see what actually happens here.
Before MVC
Web Forms have been the basic model for a developer who has been working on ASP.NET, for a long time. Web Forms was the result of Microsoft's efforts to create a web application based on windows standards. By default, web is stateless. If I send a request, this is supposed to be a request of its own, no matter what the history between me and the web server has been. To use a RESTful model, info should be sent using GET, POST requests, cookies etc. However, this model did not resemble windows applications. In order to avoid this, developers started using state management tools, like session for example.
If you are not so sure what session is, you can take a look at
this older post of mine. Now, the thing is that as applications became more and more complex so did the way we used session. People had to be extra careful that nothing bad happened to their session.
After MVC
Then MVC was introduced and people who had been watching Web Forms growing all these years along with the troubles they carried, felt like something new, pure and RESTful could happen. These people felt like in order to achieve this, all the bad stuff Web Forms contained should be sent away, session being one of them.
So, using Session in MVC projects is no different than using session in Web Forms projects. The same problems that showed up in Web Forms are still right there. Then let's take a look at a few of them and see what all the fuss is about.
-
Session by default is stored in the IIS and uses its memory. This means that if IIS needs to recycle the application pool or memory is not enough, the session will be gone. There are other places to store session e.g. the Sql server; however this is not much different than storing the info in database tables in the first place.
-
Session will expire after a while, depending on your timeout value. If you choose to increase timeout carelessly, you may end up consuming much more memory than you thought you would.
-
If you are using load balancers (and most enterprise website do so) you need to make sure that a user will get the same response no matter which server will serve him.
Conclusion
Using session on an MVC project is no different than doing so in a Web Forms project. Since choosing between using session or other ways of storing data depends on your case and your specs, there is no reason why you should not do it. If you believe that using session will do no harm to your project you may go for it, no matter what the project type is.
Back to BlogPreviousNext