Question

I see the web development world in .Net is now divided into Asp.Net Webforms and MVC and there is 3rd category who prefer to use both in the same application.

My question: ViewState is often treated as evil and the major performance bottleneck in majority of the applications. But if we use it correctly then I see no problems at all. There is too much buzz around Asp.Net MVC 3.0/4.0 beta and it being without ViewState.

However my concern is, how can Asp.Net MVC help speed up performance because as I see it we bind controls in

if (!IsPostback) {}

where in Asp.Net MVC we bind the control each and every time and possibly make database request each time a form is posted. Doesn’t Asp.Net Winforms have upper hand in this? Can it be guranteed that Asp.Net MVC will perform better in all cases?

Edit: I do not wish to start any controversy and further I am only talking about the Asp.Net code not about performance after Javascript minification, CSS minification and all other tricks.

Answer 1

All excellent answers here, but I’m going to throw my 2 cents in as well.

When you bind controls withif (!IsPostBack), you are writing an encrypted viewstate field to the webforms page. During the next request, all of that state is sent up to your server and decrypted / deserialized. If you had a GridView on the page, all of its rows would be in the viewstate, so you would not need to make another db request to databind it again.

In this sense, it could make performance better on your server. However, as others here have said, you take the network hit of sending all of that viewstate up to the server. Also, you need to push the state back down. It sounds like you are keeping your viewstate light on purpose to overcome potential viewstate abuses and make webforms perform better. That is definitely a good practice, because viewstate is often abused or even ignored.

Consider the example where you are pushing down a paginated GridView to the client. If your GV contains 15 rows, you may well be getting better performance by pushing it all down to the client, deserializing it on the way back up, and not hitting the db after the first load. When your GV contains 1500 rows though, end users would probably see better performance if you did not send it down in viewstate, and instead hit the db during each pagination request. (However as soon as they link from the GV to a detail page, then click the “Back” button, they will be asked to repost their data — which is always annoying, no matter how many rows there are).

Ultimately, the performance may look better to you when you are developing on the machine that is serving up and consuming the webforms pages. But depending on the size of your viewstate, people who access the content over a network might not see the kind of speed as you. It all depends on how fat your viewstate is.

I think one of the reasons a lot of MVC fans like it is because they only need to send the minimal request to the server that is needed to perform a specific action. Instead of having 1 monolithic form that submits all data & state for all webcontrols on a page, we can split up our forms and only send sections or chunks to different actions, instead of deserializing the entire form.

As others have said here, the short answer to your question is NO, MVC will not always be faster or perform better than webforms. There is no black and white. In many cases it can and does, but again as others have said, some apps are better suited for webforms. Also, is performance your only concern? MVC does have black & white advantages over webforms in other areas, even if performance may always “depend”.