ASP.NET Web Forms   Programming Web Forms

A Web Form consists of two components, the visual elements and the code. The visual elements are created in an .aspx file that acts as a container for HTML elements and Web Forms controls. The code can be stored in a separate class file, or both components can reside within the same .aspx file.

Although you can create Web Forms from separate components, they form a unit. When the Web Form is compiled, ASP.NET parses the page and its code, generates a new class dynamically, and then compiles the new class. The dynamically generated class is derived from the ASP.NET Page class, but is extended with controls, your code, and the static HTML text in the .aspx file.

This new derived Page class becomes a single executable file that is executed on the server whenever the Web Forms page is requested. At run time, the Page class processes incoming requests and responds by dynamically creating HTML and streaming it back to the browser. If the page contains Web controls ( as it typically would ), the derived Page class acts as container for the controls, and instances of the controls are created at runtime and likewise render HTML text to the stream.

For developers who are used to ASP, this model represents something new. In ASP, the page consisted of static HTML interspersed with executable code. The ASP processor read the page, extracted and ran only the code ( interpreted, rather than compiled ), and then fitted the results back into the static HTML before sending the results to the browser. The traditional ASP model is therefore one of HTML with code added.

In the Page class, the opposite is true. The entire Web Form is, in effect, an executable program whose output is HTML. The processing model is much more like any callable component in that the page executes as code when invoked. The page goes through a series of processing stages analogous with those of other components — initialize, process, and dispose — with a few differences.

One difference is that, like Web components generally, the Page class performs these stages each time the page is called; that is, the page is initialized, processed, and disposed every time a round trip to the server occurs. ( In fact, for efficiency the information required to recreate the page is cached, but this is independent of its lifecycle. ) A second difference is that the Page class has a distinct stage — render, during which HTML is generated — which is unique to Page classes.

When you create the page and class files for a Web Form, it generates code that derives the page from the base Page class. For example, if you create a new Web Form and name it WebPage1, you will be creating a new class WebPage1 derived from Page. In the generated code, you would see a line such as the following:

public class MyPage : Page

Public Class MyPage Inherits Page

The page ( .aspx file ) is in turn derived from the derived class, that is, from WebPage1. The relationship of the base Page class, the derived class file, and the .aspx file is illustrated in the following diagram.

Because the .aspx file is not a module in the traditional sense, its relationship to the class file is established with directives at the top of the page. Specifically, the @ Page directive’s Inherits attribute is used to specify the class file from which the .aspx file is derived. A typical directive might look like this:

<%@ Page Inherits="Project1.WebPage1" ... %>

Programming Web Forms