ASP.NET Web Form Render Engine outputs a Control Tree? Looking for info on render logic

Question

I've been watching a video on Scott Hanselmnn teaching MVC 2 tricks/tips. He mentions how MVC 2 by default uses ASP.NET Web Forms view engine to render the output of the views; he mentions that the web forms view engine is a little slower than it could be for MVC 2 since it generates a control tree and then outputs the HTML to the page (I hope I said that right).

I was wondering what he meant by web forms generating a code tree before outputting the HTML to the page. Does anyone have insight on the view engine of Web forms and the steps of the rendering process works for ASP.NET and MVC2?

Answer 1

In Web Forms, the HTML is generated by a hierarchy of controls, each of which needs to be called upon to render its HTML and each of which contributes to the Page ViewState. In addition, a lot of events are fired by Web Forms (Init, PreRender, etc) during its life cycle, and each control in the hierarchy also fires similar events.

In MVC, the process could theoretically be much simpler, as you don't have a deep hierarchy of controls, you don't have ViewState, and you don't have the need to fire events. However, MVC "piggybacks" off of the ASP.NET framework, and so behind the scenes, a lot of the Web Forms stuff is still there, although it's not needed.

Answer 2

ASP.Net WebForms was all built around the idea of "Faking" a persitent, stateful model around the stateless nature of HTTP. The idea was to give WinForms developers a familiar environment to work in, i.e. Controls, Events, Etc...

In order to do this, the markup is parsed into a collection of objects in memory that you can then reference like you would a control in WinForms:

TextBox.Text = "I hate viewstate!";

Each Control is added to a collection of Controls that represent the page to be sent back to the client. When it comes time to build the response, the engine walks through the tree collection of controls and asks each control to Render itself to the output stream. The result is what you get in the form of an HTTP Response.

In MVC this is an unnecessary step because those controls are never referenced. MVC embraces the stateless nature of the web, and instead maps posted form variables directly to Models for use by Controller Actions.