Essential ASP.NET With Examples in C# - page 82

SUMMARY

ASP.NET introduces two significant caching features to improve application performance: output caching and data caching. Output caching provides a mechanism for caching rendered versions of pages so that subsequent access to those pages will not have to go through the entire rendering process. You enable output caching on a page by specifying an OutputCache directive, in which you can control the duration the page should be cached, how many different versions of the page should be cached, and whether the page should be cached on downstream proxies and in client browsers. Output caching is also applicable to user controls, where it is called page fragment caching. Applying the OutputCache directive to an .ascx file caches the rendering of that control the first time it is used on a page.

An application-level data cache is available through the Cache property of the HttpContext class. Any object can be inserted into the data cache, and each entry in the cache has its own set of attributes that control its lifetime. Cache entries can specify how long they should stay in the cache either by specifying a fixed time when they should be removed, a duration after the most recent access after which they should be removed, or a dependency on another cache entry or file that should trigger their removal. Entries in the cache are subject to scavenging according to priority, which gives ASP.NET a last recourse for reclaiming memory before bouncing its worker process.

Chapter 10. State Management

Before we begin discussing state management in ASP.NET, let's get one thing straight: Attempting to manage state in Web applications goes against the fundamental design principles of the Web. One of the primary goals of the Web and its underlying protocol, HTTP, is to provide a scalable medium for sharing information. Adding user state inherently reduces scalability because the pages shown to a particular user will be different from those shown to another user and thus cannot be reused or cached.

In spite of this fact, many applications deployed on the Web require user-specific state to function properly. Applications ranging from e-commerce shopping sites to local company intranet sites depend on the ability to track individual requests from distinct users and store state on behalf of each client, whether it's items in a shopping cart or which days were selected on a calendar as requested vacation days. Although maintaining client-specific state is not officially part of the HTTP protocol, there is a proposal in place for adding state management to HTTP. RFC 2109 ^[14] defines a proposed standard for state management for HTTP also known as cookies. Although it is only a proposed standard and not yet an official part of the HTTP specification, cookies are in widespread use today in almost all browsers, and many Web sites rely on cookies for their functionality.

^[14] See http://www.w3.org/Protocols/rfc2109/rfc2109.

As a consequence, Web programmers must be very conscious about state management. Unlike traditional applications, Web applications must be very explicit about any state that is maintained on behalf of a client, and there is no one standard way to maintain that state.

10.1 Types of State

One of the most important decisions you face when designing a Web application is where to store your state. ASP.NET provides four types of state: application state, session state, cookie state, and view state. In this chapter, we explore each type of state, when it is most applicable , and any disadvantages you should be aware of if you decide to make use of it.

ASP.NET, like its predecessor, ASP, provides a pair of objects for managing application-level state and session-level state. Application state is where information that is global to the application may be stored. For efficiency, this state is typically stored once and then read from many times. Session state is maintained on a per-client basis. When a client first accesses any page in an application, an ASP.NET generated session ID is created. That session ID is then transmitted between the server and the client via HTTP either using client-side cookies or encoded in a mangled version of the URL (URL mangling is discussed in detail later in this chapter). On subsequent accesses by the same client, state associated with that session ID may be viewed and modified. Cookies provide the ability to store small amounts of data on a client's machine. Once a cookie is set, all subsequent pages accessed by the same client will transmit the cookie and its value.

Finally, view state is a yet another way of storing state on behalf of a client by saving and restoring values from a hidden field when a form is posted. Although this technique for retaining state has been used by Web developers in the past, ASP.NET provides a simplified mechanism for taking advantage of it. As we have seen in Chapter 8, it is possible to place items into the ViewState property bag available in every Page -derived class. When that page issues a POST request to itself, the values placed in the ViewState property bag can then be retrieved, the key restriction being that view state works only when a page posts to itself. Table 10-1 summarizes the advantages and disadvantages of each of the four types of state available in ASP.NET.

Table 10-1. State Type Comparison in ASP.NET

Type of State	Scope of State	Advantages	Disadvantages
Application	Global to the application	Shared across all clients	Overuse limits scalability Not shared across multiple machines in a Web farm or processors in a Web garden Primary purpose subsumed by data cache in ASP.NET
Session	Per client	Can configure to be shared across machines in a Web farm and processors in a Web garden	Requires cookies or URL mangling to manage client association Off-host storage can be inefficient
Cookie	Per client	Works regardless of server configuration State stored on client State can live beyond current session	Limited memory (~4KB) Clients may not support cookies or may explicitly disable them State is sent back and forth with each request
View	Across `POST` requests to the same page	Works regardless of server configuration	State is retained only with `POST` request made to the same page State is sent back and forth with each request