At its core , ASP.NET is a collection of .NET classes that work together to service HTTP requests . Some of these classes are defined in system assemblies as part of the base class libraries that are installed with the .NET runtime, some of these classes may be housed in assemblies deployed in the global assembly cache (GAC), and some of these classes are loaded from local assemblies that live in the virtual directory associated with this application. All these classes are loaded into an application domain within the ASP.NET worker process and interact to generate a response for a given request. Figure 1-1 shows this architecture. Figure 1-1. High-Level Architecture of ASP.NET
The fundamental shift that most developers face when moving to ASP.NET is the fact that everything is a class loaded from an assembly. As in other class-based architectures, you build applications in ASP.NET by constructing classes that interact with other classes in the base framework. Some of your classes will derive from base classes in the framework, others may implement interfaces defined by the framework, and still others may simply interact with base classes in the framework by calling methods on them. Although ASP-style syntax is still supported, ASP.NET files with server-side code are turned into class definitions housed in assemblies when first accessed. The end result, therefore, is a collection of classes interacting within a process to service a request. Another significant shift is the process model. The ASP.NET worker process is a distinct worker process, aspnet_wp.exe , [1] separate from inetinfo.exe (the Internet Information Server, or IIS, process), and the process model in ASP.NET is unrelated to process isolation settings in IIS. Although IIS is still typically used as the entry point to an ASP.NET application, [2] physically listening on the appropriate ports and dispatching the requests, its role has been lessened, and many of the tasks it used to handle are now handled by ASP.NET in its own worker process.
|