.NET Architecture—Features of ASP.NET
|Visual C# Tutorials|
|.NET Framework Tutorials|
|© 2006 Wiley Publishing, Inc.|
Features of ASP.NET
First, and perhaps most important, ASP.NET pages are structured. That is, each page is effectively a class
that inherits from the .NET
System.Web.UI.Page class, and can override a set of methods that are
evoked during the
Page object’s lifetime. (You can think of these events as page-specific cousins of the
OnSession_Start events that went in the
global.asa files of plain old
ASP.) Because you can factor a page’s functionality into event handlers with explicit meanings, ASP.NET pages are easier to understand.
Another nice thing about ASP.NET pages is that you can create them in Visual Studio 2005, the same environment in which you create the business logic and data access components that those ASP.NET pages use. A Visual Studio 2005 project, or solution, contains all of the files associated with an application. Moreover, you can debug your classic ASP pages in the editor as well; in the old days of Visual InterDev, it was often a vexing challenge to configure InterDev and the project’s Web server to turn debugging on.
For maximum clarity, the ASP.NET
code-behind feature lets you take the structured approach even further.
ASP.NET allows you to isolate the server-side functionality of a page to a class, compile that class
into a DLL, and place that DLL into a directory below the HTML portion. A
code-behind directive at
the top of the page associates the file with its DLL. When a browser requests the page, the Web server
fires the events in the class in the page’s
Last but not least, ASP.NET is remarkable for its increased performance. Whereas classic ASP pages are interpreted with each page request, the Web server caches ASP.NET pages after compilation. This means that subsequent requests of an ASP.NET page execute more quickly than the first.
ASP.NET also makes it easy to write pages that cause forms to be displayed by the browser, which you might use in an intranet environment. The traditional wisdom is that form-based applications offer a richer user interface, but are harder to maintain because they run on so many different machines. For this reason, people have relied on form-based applications when rich user interfaces were a necessity and extensive support could be provided to the users.
With the advent of Internet Explorer 5 and the lackluster performance of Navigator 6, however, the advantages of form-based applications are clouded. IE 5’s consistent and robust support for DHTML allows the programmer to create Web-based applications that are every bit as pretty as their fat client equivalents. Of course, such applications necessitate standardizing on IE and not supporting Navigator. In many industrial situations, this standardization is now common.