Is it a good idea to avoid state management techniques in ASP.Net MVC?

Question

Is it a good idea to avoid state management techniques(session, cookies etc) in ASP.Net MVC 3.0?

If yes then is there any other alternatives available except TempData?

Answer 1

I find that state is nicely maintained in a cache when implementing the repository pattern. In the MVC Futures project, there is also the Html.Serialize method which gives 'view state like' state storage. http://mvccontrib.codeplex.com/

For information like items bound to a combobox that we were used to having maintained automatically for us in web forms, a good alternative here is to call off to a repository for the data. The repository maintains a reference to a cache (ideally through an interface you create like - ICache). The repository then caches this data based on for ex. the current users name, key whatever. Some prefer to have a service layer cache, but I feel by design a repository layer was meant for this.

Session is still used - if you must - it has its place. A lot of 'bad' surrounds the session, but if you need to store session specific information and your site isn't concerned with a large number of hits a day, then you can likely take the hit just fine.

TempData is great for storing status messages to show on the next request such as 'record saved successfully' so you don't lose it across the redirect and don't have to pass it on the querystring. Thats about the only thing I use it for although some use it to store data for rebinding on the next request.

Answer 2

This would depend on your specific requirements. Session state and cookies for example are very different beasts.

If session state is a good fit to your requirements in WebForms then it's a good fit in MVC. There is no specific reason not to use it in MVC.

You basically only have 3 places you can store data, on the client (cookies/hidden values/query string), on the server (session/cache/static), in the database.

There is loads of documentation of the pros and cons of all these methods, a good starting place is:

http://msdn.microsoft.com/en-us/library/z1hkazw7.aspx

Answer 3

It depends.

Session and cookies were invented to solve some kind of problem, so they should be used to solve that problem.

TempData won't help much in replacing cookies - because cookies are saved on client side. Also TempData is Session, distinction is that TempData is for redirection only. As long as TempData is quite usefull in redirection scenarios, you may wish to keep session to be enabled for these scenarios.

If you don't have session oriented scenarios (like object creation has multiple steps and after first step you can't save it to database yet), you can avoid using it, but in general it is not by itself evil.

Answer 4

IMO, the rules for session state in MVC are the same as the rules in WebForms: use it if you must, but keep your usage lightweight. If you truly have some data to track per user/session, there is no need to reinvent the wheel.

Answer 5

You can save your state in the database directly