Figure 1-5: A more detailed view of the ASP.NET development stack. The arrow indicates the typical top-down application perspective, going down from the user interface to the system services.
At the highest level of abstraction, the development of an ASP.NET application passes through two phases pages authoring and run-time configuration. You build the pages that form the application, implement its user's requirements, and then fine-tune the surrounding run-time environment to make it serve pages effectively and securely. As Figure 1-2 shows, the ASP.NET component model is the bedrock of all ASP.NET applications and their building blocks. With Figure 1-2 in mind, let's examine the various logical layers to see what they contain and why they contain it.
An ASP.NET page is made of controls, free text, and markup. When the source code is transformed into a living instance of a page class, the ASP.NET runtime makes no further distinction between verbatim text, markup, and server controls everything is a control, including literal text and carriage-return characters. At run time, any ASP.NET page is a mere graph of controls.
The programming richness of ASP.NET springs from the wide library of server controls that covers the basic tasks of HTML interaction for example, collecting text through input tags as well as more advanced functionalities such as grid-based data display. The native set of controls is large enough to let you fulfill virtually any set of requirements. In addition, the latest version of ASP.NET adds a few new rich controls to take developer's productivity close to its upper limit.
In ASP.NET 2.0, you find controls to create Web wizards, collapsible views of hierarchical data, advanced data reports, commonly used forms, declarative data binding, menus, site navigation. You even find a tiny API to create portal-like pages. Availability of rich controls means reduction of development time and coding errors, more best practices implemented, and more advanced functionalities delivered to end users. We'll specifically cover controls in Chapter 4, Chapter 6, and later on in Chapter 10.
ASP.NET core controls provide you with a complete set of tools to build Web functionalities. The standard set of controls can be extended and enhanced by adding custom controls. The underlying ASP.NET component model greatly simplifies the task by applying the common principles and rules of object-oriented programming.
You can build new controls by enhancing an existing control or aggregating two or more controls together to form a new one. ASP.NET 1.x comes with a small set of base classes to build brand new controls on. This set of classes has been extended in ASP.NET 2.0, in particular to simplify the development of new data-bound controls.
Starting with version 2.0, ASP.NET ships a new control adapter architecture that allows any server control to create alternate renderings for a variety of browsers. Note, though, that the new ASP.NET 2.0 adapter model doesn't apply to mobile controls. Mobile controls are a special family of Web controls designed to build applications for mobile devices. ASP.NET 2.0 mobile controls still use the old adapter model, which was available since ASP.NET 1.1, for controls that inherit from MobileControl and are hosted on pages that inherit from MobilePage. In short, if you need to write a mobile application with ASP.NET 2.0, you should use the mobile controls, as you would have done with ASP.NET 1.1.
So what's the added value of the new adapter model? With this form of adaptive rendering, you can write control adapters to customize server controls for individual browsers. For example, you can write a control adapter to generate a different HTML markup for the Calendar control for a given desktop browser.
Any ASP.NET page works as an instance of a class that descends from the Page class. The Page class is the ending point of a pipeline of modules that process any HTTP request. The various system components that work on the original request build step by step all the information needed to locate the page object to generate the markup. The page object model sports several features and capabilities that could be grouped in terms of events, scripting, personalization, styling, and prototyping.
The life cycle of a page in the ASP.NET runtime is marked by a series of events. By wiring their code up to these events, developers can dynamically modify the page output and the state of constituent controls. In ASP.NET 1.x, a page fires events such as Init, Load, PreRender, and Unload that punctuate the key moments in the life of the page. ASP.NET 2.0 adds quite a few new events to allow you to follow the request processing more closely and precisely. In particular, you find new events to signal the beginning and end of the initialization and loading phase. The page life cycle will be thoroughly examined in Chapter 3.
The page scripting object model lets developers manage script code and hidden fields to be injected in client pages. This object model generates JavaScript code used to glue together the HTML elements generated by server controls, thus providing features otherwise impossible to program on the server. For example, in this way you can set the input focus to a particular control when the page displays in the client browser.
ASP.NET pages can be architected to issue client calls to server methods without performing a full postback and subsequently refresh the whole displayed page. This sort of remote scripting engine is implemented through a callback mechanism that offers a clear advantage to developers. When you use script callbacks, the results of the execution of a server-side method are passed directly to a JavaScript function that can then update the user interface via Dynamic HTML. A roundtrip still occurs, but the page is not fully refreshed.
Script callbacks, though, are not the only good news. Cross-page posting is another feature that the community of ASP.NET developers loudly demanded. It allows the posting of content of a form to another page. Sounds like teaching old tricks to a new dog? Maybe. As mentioned earlier in this chapter, one of the most characteristic aspects of ASP.NET is that each page contains just one <form> tag, which continuously posts to itself. That's the way ASP.NET has been designed, and it results in several advantages.
In previous versions of ASP.NET, cross-page posting could be implemented the same way as in classic ASP that is, posting through an HTML pure <form> not marked with the runat attribute. This method works fine, but it leaves you far from the object-oriented and strongly typed world of ASP.NET. Cross-page posting as implemented in ASP.NET 2.0 fills the gap.
In ASP.NET 2.0, you can store and retrieve user-specific information and preferences without the burden of having to write the infrastructural code. The application defines its own model of personalized data, and the ASP.NET runtime does the rest by parsing and compiling that model into a class. Each member of the personalized class data corresponds to a piece of information specific to the current user. Loading and saving personalized data is completely transparent to end users and doesn't even require the page author to know much about the internal plumbing. The user personalized information is available to the page author through a page property. Each page can consume previously saved information and save new information for further requests.
Much like Microsoft Windows XP themes, ASP.NET themes assign a set of styles and visual attributes to elements of the site that can be customized. These elements include control properties, page style sheets, images, and templates on the page. A theme is the union of all visual styles for all customizable elements in the pages a sort of super-CSS (cascading style sheet) file. A theme is identified by name and consists of CSS files, images, and control skins. A control skin is a text file that contains default control declarations in which visual properties are set for the control. With this feature enabled, if the developer adds, say, a DataGrid control to a page, the control is rendered with the default appearance defined in the theme.
Themes are a great new feature because they allow you to change the look and feel of pages in a single shot and, perhaps more importantly, give all pages a consistent appearance.
Almost all Web sites today contain pages with a similar layout. For some sites, the layout is as simple as a header and footer; others sites might contain sophisticated navigational menus and widgets that wrap content. In ASP.NET 1.x, the recommended approach for developers was to wrap these UI blocks in user controls and reference them in each content page. As you can imagine, this model works pretty well when the site contains only a few pages; unfortunately, it becomes unmanageable if the site contains hundreds of pages. An approach based on user controls presents several key issues for content-rich sites. For one thing, you have duplicate code in content pages to reference user controls. Next, application of new templates requires the developer to touch every page. Finally, HTML elements that span the content area are likely split between user controls.
In ASP.NET 2.0, page prototyping is greatly enhanced thanks to master pages. Developers working on Web sites where many pages share some layout and functionality can now author any shared functionality in one master file, instead of adding the layout information to each page or separating the layout among several user controls. Based on the shared master, developers can create any number of similar-looking content pages simply by referencing the master page through a new attribute. We'll cover master pages in Chapter 6.
The process by which a Web request becomes plain HTML text for the browser is not much different in ASP.NET 2.0 than in ASP.NET 1.1. The request is picked up by IIS, given an identity token, and passed to the ASP.NET ISAPI extension (aspnet_isapi.dll) the entry point for any ASP.NET-related processing. This is the general process, but a number of key details depend on the underlying version of IIS and the process model in use.
The process model is the sequence of operations needed to process a request. When the ASP.NET runtime runs on top of IIS 5.x, the process model is based on a separate worker process named aspnet_wp.exe. This Microsoft Win32 process receives control directly from IIS through the hosted ASP.NET ISAPI extension. The extension is passed any request for ASP.NET resources, and it hands them over to the worker process. The worker process loads the common language runtime (CLR) and starts the pipeline of managed objects that transform the original request from an HTTP payload into a full-featured page for the browser. The aspnet_isapi module and the worker process implement advanced features such as process recycling, page output caching, memory monitoring, and thread pooling. Each Web application runs in a distinct AppDomain within the worker process. By default, the worker process runs under a restricted, poorly privileged account named ASPNET.
| Note | In the CLR, an application domain (AppDomain) provides isolation, unloading, and security boundaries for executing managed code. An AppDomain is a kind of lightweight, CLR-specific process where multiple assemblies are loaded and secured to execute code. Multiple AppDomains can run in a single CPU process. There is not a one-to-one correlation between AppDomains and threads. Several threads can belong to a single AppDomain, and while a given thread is not confined to a single application domain, at any given time, a thread executes in a single AppDomain. |
When ASP.NET runs under IIS 6.0, the default process model is different and the aspnet_wp.exe process is not used. The worker process in use is the standard IIS 6.0 worker process (w3wp.exe). It looks up the URL of the request and loads a specific ISAPI extension. For example, it loads aspnet_isapi.dll for ASP.NET-related requests. Under the IIS 6.0 process model, the aspnet_isapi extension is responsible for loading the CLR and starting the HTTP pipeline.
Once in the ASP.NET HTTP pipeline, the request passes through various system and user-defined components that work on it until a valid page class is found and successfully instantiated. Developers can modify and adapt the run-time environment to some extent. This can happen in three ways: changing the list of installed HTTP modules, configuration files, state and personalization providers, and other application services.
HTTP modules are the ASP.NET counterpart of ISAPI filters. An HTTP module is a .NET Framework class that implements a particular interface. All ASP.NET applications inherit a few system HTTP modules as defined in the machine.config file. Preinstalled modules provide features such as authentication, authorization, and session-related services. Generally speaking, an HTTP module can preprocess and postprocess a request, and it intercepts and handles system events as well as events raised by other modules.
The good news is that you can write and register your own HTTP modules and make them plug into the ASP.NET runtime pipeline, handle system events, and fire their own events. In addition, you can adapt on a per-application basis the list of default HTTP modules. You can add custom modules and remove those that you don't need.
The behavior of ASP.NET applications is subject to a variety of parameters; some are system-level settings, some depend on the characteristics of the application. The common set of system parameters is defined in the machine.config file. This file contains default and machine-specific values for all supported settings. Machine settings are normally controlled by the system administrator, and applications should not be given writing access to the machine.config file. The machine.config file is located outside the Web space of the application and, as such, cannot be reached even if an attacker succeeds in injecting malicious code in the system.
Any application can override most of the default values stored in the machine.config file by creating one or more application-specific web.config files. At a minimum, an application creates a web.config file in its root folder. The web.config file is a subset of machine.config, written according to the same XML schema. The goal of web.config is to override some of the default settings. Beware, however, that not all settings that are defined in machine.config can be overridden in a child configuration file. In particular, the information about the ASP.NET process model can be defined only in a machinewide manner using the machine.config file.
If the application contains child directories, it can define a web.config file for each folder. The scope of each configuration file is determined in a hierarchical, top-down manner. The settings valid for a page are determined by the sum of the changes that the various web.config files found along the way applied to the original machine configuration. Any web.config file can extend, restrict, and override any type of settings defined at an upper level, including the machine level. If no configuration file exists in an application folder, the settings that are valid at the upper level are applied.
Authentication, state management, and caching are all examples of essential services that the ASP.NET runtime environment supplies to running applications. With ASP.NET 2.0, other services have been added to the list including administration, membership, role management, and personalization as shown in Figure 1-5.
Figure 1-5: A more detailed view of the ASP.NET development stack. The arrow indicates the typical top-down application perspective, going down from the user interface to the system services.
Most application services must persist and retrieve some data for internal purposes. While doing so, a service chooses a data model and a storage medium, and it gets to the data through a particular sequence of steps. Applications based on these services are constrained by the design to using those settings which usually includes a fixed data schema, a predefined storage medium, a hard-coded behavior. What if you don't like or don't want these restrictions?
Run-time configuration, as achieved through machine.config and web.config files, adds some more flexibility to your code. However, run-time configuration does not provide a definitive solution that is flexible enough to allow full customization of the service that would make it extensible and smooth to implement. A more definitive solution is provided by ASP.NET 2.0, which formalizes and integrates into the overall framework of classes a design pattern that was originally developed and used in several ASP.NET Starter Kits. Known as the provider model, this pattern defines a common API for a variety of operations each known as the provider. At the same time, the provider's interface contains several hooks for developers to take complete control over the internal behavior of the API, data schema used, and storage medium.
| Important | The provider model is one of the most important and critical aspects of ASP.NET. A good understanding of it is crucial to conduct effective design and implementation of cutting-edge applications. The provider model is formalized in ASP.NET 2.0, but it is simply the implementation of a design pattern. As such, it is completely decoupled at its core from any platform and framework. So once you understand the basic idea, you can start using it in any application, even outside the boundaries of ASP.NET. |
