ASP.NET Web Forms Weaknesses
(Page 1 of 5 )
Last time we began comparing ASP.NET Web Forms with ASP.NET MVC. We examined the strengths of Web Forms. This time we will start by taking a close look at its weaknesses. This is the second part of a four-part series.
The Weakness of ASP.NET Web Forms
On the whole, the weakness of the traditional ASP.NET Web Forms solution mainly lies in the following four aspects. Let's check each of them one by one.
(1) ViewState and Postbacks
Maybe the most disputable point people often bring forward about ASP.NET Web Forms relates to ViewState and Postbacks. To introduce an event-driven approach and overcome the stateless nature (and also obstacle) of HTTP protocol to simulate the old Windows form model development experience, ASP.NET Web Forms introduces ViewState and Postback. The end result is both ViewState and Postbacks have caused lots of problems and increased the complexity of web application development. Even simple web pages can produce a ViewState larger than 100KB in size that heavily affects the performance of the application sometimes.
Is ViewState is a must have in an ASP.NET application? In fact, most existing web pages usually feature a good many hyperlinks. When you click one of the links, you will be navigated to a new page. Since clicking the links will lead you to another page, what is the use of ViewState within the page? In practice, when I start to write a new web project, the first thing I do is turn off the enableViewState (and sometimes enableSessionState) parameter from inside the Web.config file.
Some may ask me what sense there is to using Web Forms since I turn off ViewState. My answer is: there are many reasons. Web Form provides a control model, and so users can take advantage of the easy-to-grasp mode to set/get the value of a text box, and also, they can use many button events easily to write related event handlers to trigger various business logics. Moreover, using Web Forms is simple and clear.
Well, without ViewState why can you use the events of the controls? Of course, you can if the events are not complex ones. Here is an example. The TextBox's TextChange event belongs to complex events, as well as the Command event of the GridView control. However, the click event of a Button control is the "simple event."
As with the event, there are also complex states and simple ones. Take, again, for example: the state of each sub-control within each line inside the GridView control is a "complex state," while the Text property of a TextBox control belongs to a "simple state." "Complex states" and "complex events" require ViewState, while the simple ones do not. So, why not try to use simple states and events instead of complex ones?
One of the most prominent and significant features of ASP.NET Web Forms lies in its powerful (and complex) component model. Inside this model was introduced something named "page life cycle." Many people threw stones at it and accused it of killing system performance. In essence, this complex life-cycle does, at some times, run without any efficient result again and again. However, assuming that the ASP.NET "page life cycle" kills performance is not right.
Suppose that you put 1,000 to 10,000 button controls on an .aspx page. I pledge that the application runs quickly. In real environments, what leads to low efficiency lies in many aspects: the database access solution, the buffer mechanism, asynchronous invocation, the web server related payload balance, and so forth. These factors need to be carefully taken into consideration.
Next: The HTML Tag Weakness >>
More ASP.NET Articles
More By Xianzhong Zhu
