asp.net c# MVC: How do I live without ViewState?

Question

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?

Answer 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.

Answer 2

Consider the fact that the REST movement in web programming is predicated on the idea that state is bad for a program. The Wikipedia has a decent description with references: http://en.wikipedia.org/wiki/Representational_State_Transfer

Coming from tranditional ASP.NET and the rich event model it provides, MVC can be quite jarring. It does require managing some things that were invisible to you before, but I think that the value in terms of testability (REST pages can be triggered easily without creating a complex viewstate and by definition the server isn't holding state so I can test a page/feature in isolation) offsets the learning curve.

For some discussion of MVC in ASP.NET and REST: http://blog.wekeroad.com/2007/12/06/aspnet-mvc-using-restful-architecture/

Answer 3

You can imitate view state with MVC3Futures project. It will save the whole model in view.

All you have to do is to serialize model and encrypt it in view.

@Html.Serialize("Transfer", Model, SerializationMode.EncryptedAndSigned)

And in controller add deserialized attribute.

public ActionResult Transfer(string id,[Deserialize(SerializationMode.EncryptedAndSigned)]Transfer transfer)

Answer 4

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.

Answer 5

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).

Answer 6

All of the answers saying that ASP.NET MVC does not use state are pretty much correct. But ASP.NET MVC does in fact use some state, although it does not work anything like ViewState.

Usually, when someone POSTs data to your application, you will want to validate the data and display an error if the data are not valid. However, if you just return the page containing the error message immediately, when the user hits F5 to reload the page, the data will be resubmitted. This is usually not what you want. Thus, when you realize that the data POSTed are not valid, you want to tell the users to GET the page (or perhaps another page) and show an error message. You do that by returning an HTTP Redirect status code. However, once the user's GET request comes in, how do you know what error message to display? You will have to somehow remember this from the time you (the server) are handling the POST until you are handling the GET.

To do this you use an ASP.NET MVC feature called TempData. This is actually just a wrapper around Session which ensures that whatever you shove into the TempData dictionary will stay there until the next request and no longer.