Microsoft could have sustained or even increased the popularity of ASP as a Web application platform with incremental improvements, such as a more powerful language for server-side scripting or page compilation to improve performance. In fact, ASP.NET offers both of these features—but it also offers quite a bit more. Simply put, ASP.NET is a revolution. In this article, I’ll discuss the improvements ASP.NET brings to Web programming.
In the ASP model, a page is defined through HTML and extended with embedded scripting. In ASP.NET, on the other hand, a page is a class that generates HTML. This model is called WebForms. If the name makes you think of VB6 forms or .NET WinForms, you’re headed in the right direction. With WebForms, Web server controls are placed on a page. When the page is accessed, the controls render themselves as HTML. Roundtrips between the browser and server are managed transparently to enable event handling, much as with WinForms.
The Greeter page
Let’s dive right in to an example called Greeter to see how this works. I like to strip things down to the essentials and then build up when I’m learning a new technology. Greeter simply prompts for a name and then issues a greeting, but it demonstrates several of the key features of ASP.NET.
The Greeter page is defined in two files: Greeter.aspx, in Listing A, and Greeter.aspx.cs, in Listing B. The .aspx file defines the page UI, and the C# file (Visual Basic.NET or JScript.NET could also be used) implements the page logic in the GreeterLogic class. The @ Page directive on the first line of Greeter.aspx binds the UI to the logic through inheritance. The ClassName attribute within the directive specifies the name of the UI class as GreeterUI. The Inherits attribute specifies that GreeterUI be derived from GreeterLogic.
Web server controls
Several Web server controls are declared within the page’s <form> tag. Web server controls are the WebForms abstraction of standard HTML tags. They provide event notifications and generally offer richer functionality than standard HTML. A Web server control is declared with an XML tag that references the asp namespace. The id attribute in each server control links the control to a protected field in the base class. Each Web server control declaration in the .aspx file causes an instance of the control to be created when the page is executed. The reference to each instance is held in the corresponding base class field. This provides the base class with access to the controls and enables it to program the controls and handle events generated by the controls. Each Web server control specifies the attribute runat=”server” to indicate that the control executes on the Web server to render HTML that is appropriate for the target Web browser. The initial state of Greeter is shown in Figure A.
Figure A |
![]() |
Initial state of Greeter screen |
The first four Web server controls are fairly straightforward: labels, a text box, and a submit button. The last control, <asp:RequiredFieldValidator>, is different. A validation control checks the state of another control and prevents the form from being submitted if the target control is not in a valid state. In Greeter, the RequiredFieldValidator control is used to verify that a value has been entered in the text box control. It doesn’t care what the value is. Initially, the RequiredFieldValidator control is invisible. If the button is clicked when the text box is empty, no button click event is generated, and the RequiredFieldValidator control displays the ErrorMessage attribute value, as shown in Figure B. For uplevel browsers, the RequiredFieldValidator control generates JavaScript to perform the validation on the client side. A roundtrip to the server is required for downlevel browsers. ASP.NET provides several validation controls in addition to RequiredFieldValidator.
Figure B |
![]() |
Greeter screen with validation error message |
The GreeterLogic class
The GreeterLogic class inherits from System.Web.UI.Page. It declares protected fields to hold references to the controls created in Greeter.aspx.GreeterLogic defines two methods. The OnInit method overrides Page.OnInit to add a delegate for the m_Button_Click method to the m_Button click event. OnInit is called by ASP.NET to provide an opportunity for the page to perform initializations. The m_Button_Click method handles the click event generated by the m_Button Web server control. The click event triggers a roundtrip to the server. Back on the server, ASP.NET re-creates the page and restores the state of the Web server controls. The text box value is then available through the TextBoxText property. Figure C shows the response generated by m_Button_Click.
Figure C |
![]() |
Response by Greeter |
Deploying Greeter
To deploy the Greeter application, follow these steps:
- · Create an application directory.
- · Create a bin subdirectory in the application directory.
- · Place Greeter.aspx in the application directory.
- · Compile Greeter.aspx.cs to a library assembly with the command csc /t:library /out:Greeter.dll Greeter.aspx.cs and place Greeter.dll in the application bin subdirectory.
- · Create an IIS virtual directory that refers to the application directory.
The .aspx class generation
ASP.NET applications are processed by the IIS ISAPI filter aspnet_isapi.dll. On first access, the ISAPI filter generates a .NET class, under the ASP namespace, from Greeter.aspx and compiles it to a library assembly. The assemblies in the application’s bin subdirectory are searched automatically to locate the GreeterLogic base class. Figure D shows the inheritance hierarchy for the generated class. The generated assembly is placed in a directory for temporary ASP.NET files according to the application’s virtual directory name. For example, if the virtual directory for Greeter is named IntroASPNET, an assembly with a name like effla-hh.dll might be generated for Greeter.aspx and might be placed in a directory such as
C:\WINNT\Microsoft.NET\Framework\v1.0.3328\Temporary ASP.NET Files\introaspnet\b5d8b0af\51648ab7.
If Greeter.aspx is modified, the ISAPI filter automatically regenerates the assembly on the next page access.
Figure D |
![]() |
The inheritance hierarchy for Greeter |
ASP.NET is bona fide OO
So what does all this add up to? ASP.NET provides a truly object-oriented programming model. WebForms enable the page UI to be cleanly separated from page logic and then recombined through inheritance. No more spaghetti pages of HTML and VBScript. Page logic is implemented using a full-strength .NET language such as C#, Visual Basic.NET, or Jscript.NET. Further, the page logic implementation has the entire .NET base class libraries at its disposal. Web server controls encapsulate the differences between Web browsers and allow you to design pages at a higher lever. Everything is compiled to Microsoft intermediate language (MSIL) and converted on the fly to native code at runtime. No more sluggish performance from interpreted pages. If this isn’t revolutionary, I need a new dictionary.