Programming Microsoft ASP.NET 4 - Dino Esposito [347]
ASP.NET provides state management facilities at four levels: application, session, page, and request. Each level has its own special container object, which is a topic we’ll cover in this chapter. In this chapter, we’ll explore the HttpApplicationState, HttpSessionState, and ViewState objects, which provide for application, session, and page state maintenance, respectively. In the next chapter, we’ll dive into the Cache object.
Note
In this chapter, we won’t discuss cookies in detail, but cookies are definitely useful for storing small amounts of information on the client. The information is sent with the request to the server and can be manipulated and re-sent through the response. The cookie is a text-based structure with simple key/value pairs, and it consumes no resources on the server. In e-commerce applications, for example, cookies are the preferred way of storing user preferences. In addition, cookies have a configurable expiration policy. The negatives for cookies are their limited size (browser-dependent, but seldom greater than 8 KB) and the fact that the user can disable them.
The Application’s State
Table 17-1 summarizes the main features of the various state objects.
Table 17-1. State Management Objects at a Glance
Object
Lifetime
Data Visibility
Location
Cache
Implements an automatic scavenging mechanism, and periodically clears less frequently used contents
Global to all sessions
Does not support Web farm or Web garden scenarios
HttpApplicationState
Created when the first request hits the Web server, and released when the application shuts down
Same as for Cache
Same as for Cache
HttpContext
Spans the entire lifetime of the individual request
Global to the objects involved with the request
Same as for Cache
HttpSessionState
Created when the user makes the first request, and lasts until the user closes the session
Global to all requests issued by the user who started the session
Configurable to work on Web farms and gardens
ViewState
Represents the calling context of each page being generated
Limited to all requests queued for the same page
Configurable to work on Web farms and gardens
The HttpApplicationState object makes a dictionary available for storage to all request handlers invoked within an application. An instance of the HttpApplicationState class is created the first time a client requests any resource from within a particular virtual directory. Each running application holds its own global state object. The most common way to access application state is by means of the Application property of the Page object. Application state is not shared across either a Web farm or Web garden.
Important
Application state exists today mostly for compatibility reasons, and I don’t know of any application where Application is used instead of the more powerful and built-in Cache object or external distributed cache engines.
Properties of the HttpApplicationState Class
The HttpApplicationState class is sealed and inherits from a class named NameObjectCollectionBase. In practice, the HttpApplicationState class is a collection of pairs, each made of a string key and an object value. Such pairs can be accessed either using the key string or the index. Internally, the base class employs a hashtable with an initial capacity of zero that is automatically increased as required. Table 17-2 lists the properties of the HttpApplicationState class.
Table 17-2. HttpApplicationState Properties
Property
Description
AllKeys
Gets an array of strings containing all the keys of the items currently stored in the object.
Contents
Gets the current instance of the object. But wait! What this property returns is simply a reference to the application state object, not a clone. It’s provided for ASP compatibility.
Count
Gets the number of objects currently stored in the collection.