Not Your Father's ASP

During the past several years, Microsoft's Active Server Pages (ASP) Web-development technology has become one of the most-used tools for developing dynamic, data-driven Web applications. Now, Microsoft has introduced ASP.NET, a successor to ASP that dramatically improves on ASP's performance, reliability, and speed of development. Just how different is the new ASP.NET Web-development technology from the ASP that developers know and (mostly) love? In terms of migrating existing pages, ASP.NET isn't all that different, and much of your current ASP code will run fine under ASP.NET. You can also run ASP pages side by side with ASP.NET applications (although ASP and ASP.NET applications don't share application or session states), so you don't have to migrate all at once. But at its heart, ASP.NET is as different from ASP as a Hemi 'Cuda is from a VW Beetle. Both of them can get you where you need to go, but one is vastly more powerful than the other and gives you more options for customization. Part of that power comes from ASP.NET's tight integration with Microsoft's next-generation data-access technology, ADO.NET, which gives you robust and high-performance data binding.

What else makes ASP.NET so much more powerful than ASP? For starters, it's built on Microsoft's new .NET platform, a set of technologies that provides a modernized, language-independent replacement for the Win32 APIs. Some characteristics of ASP.NET are

• use of fully compiled, instead of interpreted, languages
• simplified programming model similar to that of Visual Basic (VB)
• a wealth of built-in functionality in the .NET Framework Class Library
• improved performance and scalability, manageability, code separation, customization, and reuse
• new, more powerful database and XML programming model

Let's look at these new features and improvements and explore how you can take advantage of them in your ASP.NET applications. Also, see the sidebar "Namespaces and Assemblies," page 38, for definitions of some terminology that's new to ASP.NET.

Fully Compiled Languages and the CLR
One of the most important differences between ASP and ASP.NET is their underlying technology. ASP is implemented as an Internet Server API (ISAPI) DLL (asp.dll) that intercepts and processes requests for .asp files. The DLL parses through the requested file and interprets any ASP code it finds, then returns the combined result of any static HTML the file contains and any output from executing the interpreted code. ASP developers who want to control the output their pages send to the browser are largely limited to the methods and properties of ASP's Response object.

ASP.NET is also implemented as an ISAPI DLL (aspnet_isapi.dll). This DLL intercepts requests to Microsoft IIS for ASP.NET pages (these pages use the .aspx extension) and passes them to the ASP.NET worker process, which fulfills the request.

ASP.NET uses compiled, rather than interpreted, languages. So instead of VBScript or JavaScript, developers can write code in Visual Basic.NET (VB.NET), C#, JScript.NET, or any other .NET-compatible language. ASP.NET also gives developers much greater control over the Request-Response cycle. You can create HttpHandlers to provide custom handling of HTTP requests and HttpModules to provide custom support services for your applications. In fact, ASP.NET implements session state as an HttpModule; in ASP, session-state support is integrated in ASP itself. Implementing session state as an HttpModule lets you disable session state or even replace it with your own custom session-state HttpModule.

Underlying the new technologies of ASP.NET is the .NET Common Language Runtime (CLR), which works with all .NET languages. With ASP.NET, you don't have to write and compile VB code that requires a VB runtime or write Visual C++ (VC++) code that requires the Microsoft Foundation Classes (MFC) runtime. All your application's executable code, whether you write it in VB.NET, C#, JScript.NET, Managed C++, or another .NET language, is ultimately executed by a single runtime, the CLR. All the language compilers in the .NET world compile your code into language-neutral intermediate language (IL). The CLR then executes the IL, just-in-time (JIT)—compiling the IL code into processor-specific binary code. One distinct advantage of this model is that it lets you create, in any .NET language, classes that any other .NET language's classes can inherit. Another advantage is that this model enables cross-language debugging.

Simplified Programming Model
ASP.NET also introduces a new Web-programming model that's based on the highly successful—and highly productive—VB model. In this new model, instead of working with static HTML code and scripts within a page, you can use ASP.NET's new Server Controls. Server Controls are tag-based controls, similar to VB controls (e.g., TextBox, Label), that provide simple programmability and built-in support for managing their own state. Server Controls provide programmability on the server while rendering cross-browser—compatible HTML to the client, so any HTML 3.2—compatible browser can use these controls (note that some controls can also optionally render Dynamic HTML—DHTML—content for uplevel browsers).

In the Visual Studio.NET (VS.NET) environment, you can place controls visually on the page in much the same way as you can in VB. Then, you can write server-side code to handle the events these controls expose. Listing 1, page 34, shows an ASP.NET page that creates Label, TextBox, and Button Server Controls. Note that you must enclose Server Controls within a set of <form> tags with the runat="server" attribute if you want to take full advantage of ASP.NET features such as automatic postback handling and automatic management of control state.

You implement Server Controls just as you do other HTML tags, except that you preface them with the asp: namespace indicator. Two important attributes that Server Controls use are the id attribute, which specifies a name by which your server-side code can refer to the control, and the runat attribute, which is required for all Server Controls (and is always set to the literal server). Figure 1 shows the output of Listing 1.

ASP.NET also exposes server-side events that developers can write event handlers for, including Page_Load and Page_Unload. ASP.NET automates the process of handling postbacks—pages that post to themselves—so one page can both display input forms and process the form input through code you write. ASP.NET pages expose an IsPostBack property that lets you check whether the current request is the result of a postback. Listing 2 expands on the code in Listing 1, adding a handler for the Page_Load event that responds to a postback.