nderstanding how ASP.NET really works under the covers can help you make decisions that can make your ASP.NET applications better. Understanding the innards of a platform always provides me with a certain satisfaction and level of comfort, as well as insight that helps me write better applications. Knowing what tools are available and how they fit together as part of the whole complex framework makes it easier to find the best solution to a problem and, more importantly, helps in troubleshooting and debugging of problems when they occur. The goal of this article is to look at ASP.NET from the system level to help you understand how requests flow into the ASP.NET processing pipeline. You'll look at the core engine and how Web requests end up there. Much of this information is not something that you need to know in your daily work, but it's good to understand how the ASP.NET architecture routes requests into your application code that usually sits at a much higher level.
Most people using ASP.NET are familiar with Web Forms and Web services. These high level implementations are abstractions that make it easy to build Web-based application logic and ASP.NET is the driving engine that provides the underlying interface to the Web server and routing mechanics to provide the base for these high level front end services typically used for your applications. Web Forms and Web services are merely two very sophisticated implementations of HTTP handlers built on top of the core ASP.NET framework.
However, ASP.NET provides much more flexibility at a lower level. The HTTP runtime and the request pipeline provide all the same power that went into building the Web Forms and WebService implementations; these implementations were actually built with .NET managed code. And all that same functionality is available to you, should you decide you need to build a custom platform that sits at a level a little lower than Web Forms.
Web Forms are definitely the easiest way to build most Web interfaces, but if you're building custom content handlers, or have special needs for processing the incoming or outgoing content, or you need to build a custom application server interface to another application, using these lower level handlers or modules can provide better performance and more control over the actual request process. With all the power that the high level implementations of Web Forms and Web services provide they also add quite a bit of overhead to requests that you can bypass by working at a lower level.
What Is ASP.NET?
Let's start with a simple definition: What is ASP.NET? I like to define ASP.NET as follows:
ASP.NET is a sophisticated engine using managed code for front-to-back processing of Web requests. It's much more than just Web Forms and Web services.
ASP.NET is a request processing engine. It takes an incoming request and passes it through its internal pipeline to an end point, where you, as a developer, can attach code to process that request. This engine is actually completely separated from HTTP or the Web server. In fact, the HTTP runtime is a component that you can host in your own applications outside of IIS or any server side application altogether. For example, you can host the ASP.NET runtime in a Windows form.
|The entire ASP.NET engine was completely built in managed code and all extensibility is provided via managed code extensions.|
The runtime provides a complex yet very elegant mechanism for routing requests through this pipeline. There are a number of interrelated objects, most of which are extensible either via subclassing or through event interfaces at almost every level of the process, so the framework is highly extensible. Through this mechanism it's possible to hook into very low level interfaces such as caching, authentication, and authorization. You can even filter content by pre or post processing requests or simply route incoming requests that match a specific signature directly to your code or another URL. There are a lot of different ways to accomplish the same thing, but all of the approaches are straightforward to implement, yet provide flexibility in finding the best match for performance and ease of development.
The entire ASP.NET engine was completely built in managed code and all of the extensibility functionality is provided via managed code extensions. This is a testament to the power of the .NET Framework in its ability to build sophisticated and very performance-oriented architectures. Above all though, the most impressive part of ASP.NET is the thoughtful design that makes the architecture easy to work with, yet provides hooks into just about any part of the request processing.
With ASP.NET you can perform tasks that previously were the domain of ISAPI extensions and filters on IIS-with some limitations, but it's a lot closer than say ASP was. ISAPI is a low level Win32 style API that had a very meager interface and was very difficult to work for sophisticated applications. Since ISAPI is very low level it also is very fast, but fairly unmanageable for application-level development. So, ISAPI has been mainly relegated for some time to providing bridge interfaces to other applications or platforms. But ISAPI isn't dead by any means. In fact, ASP.NET on Microsoft platforms interfaces with IIS through an ISAPI extension that hosts .NET and through it the ASP.NET runtime. ISAPI provides the core interface from the Web server and ASP.NET uses the unmanaged ISAPI code to retrieve input and send output back to the client. The content that ISAPI provides is available via common objects like HttpRequest and HttpResponse that expose the unmanaged data as managed objects with a nice and accessible interface.