Chapter 13 State Management

Overview

All real-world applications of any shape and form need to maintain their own state to serve users' requests. ASP.NET applications are no exception, but unlike other types of applications, they need special system-level tools to achieve the result. The reason for this peculiarity lies in the stateless nature of the underlying protocol that Web applications still rely upon. As long as HTTP remains the transportation protocol for the Web, all applications will run into the same trouble figuring out the most effective way to persist state information.

Application state is a sort of blank container that each application and programmer can fill with whatever piece of information makes sense to persist: from user preferences to global settings, from worker data to hit counters, from lookup tables to shopping carts. This extremely variegated mess of data can be organized and accessed according to a number of different usage patterns. Typically, all the information contributing to the application state is distributed in various layers, each with its own settings for visibility, programmability, and lifetime.

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, along with 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. In Chapter 12, you will recall, we covered the HttpContext object, which is the primary tool used to manage state and information across the entire request lifetime. The context of the request is different from all other state objects in that the request has a limited lifetime but passes through the entire pipeline of objects processing an HTTP request.