1

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.

Jack
  • 7,433
  • 22
  • 63
  • 107
  • 3
    Probably you would like to see this: http://stackoverflow.com/questions/43743/asp-net-mvc-performance – Falaque May 18 '12 at 12:21
  • You are asking for absolute guarantees so I would feel safe in saying "No, there is not guarantee." and feel very comfortable with that answer. There are too many factors to get in to but in my experience, it generally has a lighter, faster feel to it for equivalent pages. Don't forget that there is performance over the network for transferring ViewState for connections that aren't localhost and the browser has to deal with that in the DOM, etc. Not all performance items are in the ASP.NET pipeline. – Jared Peless May 18 '12 at 12:23
  • 1
    No. There are many, many factors of web application performance. You can write terrible MVC code, perhaps not as easily as in WebForms, but it is still possible. More than anything, having a good understanding of the web application pipeline and performance bottlenecks (agnostic of any framework) is key. – jrummell May 18 '12 at 12:36

4 Answers4

2

I can't say that MVC's advantage is performance, though I think it probably is faster. It's advantage is not dealing with the winforms-like lifecycle of controls. Development does not become more complex the more there is on a single page, where with controls, their lifecycle events can oftent step on each other if not done right.

Regarding performance, MVC's lifecycle is static. There are a handful of events that occur, but that doesn't change much. Performance concerns are in your action method. With webforms, several events and control recreation occurs on every postback, often even if the controls aren't used or visible. There is much more waste in webforms, which makes MVC by contrast lean and open to better performance.

Thinking Sites
  • 3,494
  • 17
  • 30
2

mvc (be it MS or any other framework) are more inline with the stateless nature and concepts of web.

webforms is designed to make web development behave more like a stateful desktop client. this is why page events, postback and viewstate exist.

I have seen viewstates that are 50MB. this definitely hurts performance. using an mvc framwork you can reduce page size rather quickly. however the advantages in mvc are 1. it's simplicity (vs webforms page life cycle) and 2. it's extensiblity.

if you don't like the default implementation of the controller factory, or validation, or view engine you can swap it out in mvc. with webforms you cannot.

Jason Meckley
  • 7,589
  • 1
  • 24
  • 45
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".

Community
  • 1
  • 1
danludwig
  • 46,965
  • 25
  • 159
  • 237
  • I liked your answer the most. However I am not pushing 1500 rows to client :). At max I server 50 rows having 7 columns at max :). Btw, it is not encrypted it's encoded(Base64). – Jack May 18 '12 at 16:22
  • That's good, but you didn't mention that in your original question. I was just trying to explain why there is "buzz" around MVC over webforms, and how it can perform better in some cases. – danludwig May 18 '12 at 16:27
  • There are other security questions that I have regarding MVC. Probably I will post it in other questions. Not today, my quota of 6 quetions/day are already over :). – Jack May 18 '12 at 16:30
  • RE Performance, keep in mind there are other things you can do to make an application perform better in MVC or WebForms -- such as caching, scaling up/out, and CDN. – danludwig May 18 '12 at 16:36
0

It is my personal opinion that MVC is better suited for sites that need to display lighter content. But if you need to build grids for day traders, then Web Forms have the upper hand.

ASP.net MVC does not bind controls in the way that asp.net web forms does.

You need to use JQuery in order to do this. Jquery has excellent performance.

http://www.codeproject.com/Articles/305308/MVC-Techniques-with-JQuery-JSON-Knockout-and-Cshar

It also important to mention that MVC\jquery require a much higher level of expertise. So you have to watch the bottom line when it comes to cost. Cost is usually ignored by programmers, but it plays an important role in any project.

Internet Engineer
  • 2,514
  • 8
  • 41
  • 54