Previous Section  < Day Day Up >  Next Section

17.8. Summary

The ASP.NET environment offers a variety of types and configuration files that enable a developer or software architect to customize how Web requests are handled by a server. Configuration files such as web.config provide a flexible and easy way to customize the ASP.NET settings. These files contain sections that enable/disable tracing, specify the default culture of a page, define the way session state information is stored, and define an authentication/authorization security model. The security model enables an application to limit page access to users based on credentials such as their name, password, and role. Credential information may be stored in the web.config file, an XML file, or an application's proprietary database.

ASP.NET provides several mechanisms for handling both Application and Session state data. The application data is available to all sessions using that application; session data is limited to the individual session and can be configured to support Web farms and permanent storage in a database. An alternative to using an application state object is data caching. ASP.NET provides an area in memory where CacheEntry objects are stored and made available to all sessions. Output caching is also supported to enable an entire Web page or Web page fragment to be stored in a cache on the server, a proxy server, or the browser. This reduces the load on a server by allowing a Web page to be retrieved from memory rather than being recreated on the server.

Advanced Web application development can benefit from an understanding of the underlying ASP.NET architecture that supports HTTP communications. Central to this is the HTTP pipeline through which requests and responses are transported. After a request or response enters this pipeline, it can be parsed, modified, rerouted, or rejected. Both the global.asax file and HTTP module can be designed to respond to pipeline events. The event handlers they supply are used to do such things as append standard information to all responses, maintain Web statistics, and transparently reroute requests when necessary. At the end of the pipeline, a handler is responsible for providing the requested resource. Custom handlers can be written to handle specially defined resources or enhance the existing handlers.

    Previous Section  < Day Day Up >  Next Section