asp.net c# MVC: How do I live without ViewState?
I am just looking into converting WebForms to MVC:
In .net MVC, what concepts make ViewState something thats not required?
If a form is posted back on iteself etc (ie a postback)? how does the page/usercontrol maintain its state?
What tricks are people doing to maintain some kind of state and not resort to session state?
Surely, a completely stateless environment cant exist?
Solution 1:
But of course it can. In fact, the web is stateless. Any thoughts to the contrary are the aberration, in fact.
Web Controls are gone in MVC. There are no events firing on the server side. This is replaced by two different mechanisms--URLs and POSTing form data. Proper use of these will replace your need for the ViewState.
In a conventional ASP.NET web application, you would place a LinkButton on your webpage that would perform function X. ASP.NET would stick lots of ViewState cruft, javascript and other stuff into the webpage so that, when the user clicks on the button and "posts back" to the website (by submitting a form nobody knows existed), ASP.NET reconstructs what happened and determines a particular button event handler must be executed.
In MVC, you construct your link to access a particular route. The route describes what the user wishes to do--/Users/Delinquent/Index (show a list of all delinquent users). The routing system in MVC determines which Controller will handle this route and which method on that controller will execute. Any additional information can be transmitted to the controller method by URL query string values (?Page=5 for the 5th page of delinquents).
In addition to URLs, you can use HTML forms to POST back more complex information (such as a form's worth of data) or things that won't fit in a query string, such as a file.
So you "maintain" state via query strings and form POST values. You'll find that, in fact, there isn't that much state to maintain in the end. In fact, having to maintain lots of state is a good indication that your design is lacking or that you're trying to do something that doesn't fit a website model.
Solution 2:
Some related questions:
- Maintaining viewstate in Asp.net mvc?
- ASP.NET MVC doesn't work with ViewState and Postback?
In most traditional web languages the concept of a stateful environment is actually quite uncommon. ASP.NET Webforms is an exception to the rule and it creates that exception by reinventing a lot of standards. The goal behind Webforms is essentially to abstract the concept of HTML and web development in general so that the line between desktop application and web application blurs from a development standpoint. What this generally tends to mean is that the solution that ASP.NET Webforms provides, although effective, is a jack-of-all-trades implementation which results in some very verbose output that works well enough to satisfy most. Conversely, the core advantage of ASP.NET MVC is that it gives HTML output control back to the developer and allows them to create strongly-architected, RESTful web applications that are better defined and cleaner in their implementation and presentation- despite sacrificing some level of convenience.
Arguably, one of the largest drawbacks of the Webforms model is the ViewState because it clutters the output, increases the page size dramatically in certain scenarios, and is often the equivalent of using a jackhammer to hang a picture. Rather than trying to make use of ViewState in your MVC application (or anything resembling it), you should begin to use patterns which explicitly control the fields in your forms and optimize your input and output operations with only the most relevant data. In addition to the changes in markup, you will also learn to build better designed solutions that can be exposed within your application and externally.
The number one comparison I like to make is simply: Webforms builds Web Pages, but MVC builds Web Applications. If your day-to-day work is primarily building pieces of a website, or adding small chunks of functionality, you will often find Webforms to be much easier and less time consuming; on the other hand, if you want to build a complete application that is testable, scalable, and flexible, MVC is your calling.
Solution 3:
viewstate is just a big, ugly hidden form field.
Write out your own hidden form fields, and encrypt them if you have to.
Fortunately, there's no longer any simple way to dump lots and lots of data into the page, so you have to be judicious about what you want to save.
Solution 4:
If a form is posted back on itself etc (ie a postback)? how does the page/usercontrol maintain its state? What tricks are people doing to maintain some kind of state and not resort to session state?
The posted ViewData (or strongly-typed object bound to the page) can be pushed out to the view again. See "Integrating Validation and Business Rule Logic with Model Classes" in this page. It shows how you can post a form, validate it, and return the fields back to the form if an error occurs.
In .net MVC, what concepts make ViewState something thats not required?
Representational State Transfer (REST).
Solution 5:
MVC has some advantages over WebForms but it also has some disadvantages as well as I covered detail in this answer. I think the fundamental question that you have to ask yourself is whether ViewState is a problem for you now - and is it such a problem that you must rewrite your application? If not, then Learning MVC is a worthy goal (it really is quite cool) but not one that I'd risk business for.
With that being said, ViewState can actually be disabled in a surprisingly large number of cases. It is used primarily to persist the value of controls through a post-back. So, for example, if you have a text box whose value you must check on the server side as well as a bunch of other fields, ViewState will let you handle the post-back, catch the error (and show a label) and then return the user to the form with all of their entries intact. However, if a form is only going to be filled out and posted back and you'll then be redirecting to another page, you can safely disable it.
Finally, you ask what people are doing to avoid Session state. Is there a reason to avoid session state? Surely you don't want much information there but avoiding it altogether is really not necessary and, in fact, will cost you one of the most powerful tools in your arsenal.