.NET Architecture—Features of ASP.NET

Jump to: navigation, search
Visual C# Tutorials
.NET Framework Tutorials

.NET Architecture

© 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 OnApplication_Start and 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 code-behind DLL.

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.


prevpp.png  nextpp.png
C# Online.NET