As we've seen so far, one of the most distinctive aspects of Web-based development is the requirement to be very mindful of the state of your application. By itself, raw Web application development includes no support for dealing with state. After all, Web requests are made over a disconnected protocol and the state of a request evaporates as soon as it hits an endpoint.
In Chapter 4 (all about server-side controls in depth), we took a look at the notion of view state within an ASP.NET application. ASP.NET server-side controls have the option of supporting view state. View state is embedded within the data going back and forth between the browser and the server and is used (most of the time) to keep the user interface appearing as though the browser and the server are connected continually. For example, without view state (or some special coding within the server), UI elements such as combo boxes lose their state between posts, causing the first item in the list to always show as the selected item—even if it wasn't really the item selected.
In Chapter 13, we looked at session state—or the data accompanying a specific session. Session state is useful for items such as shopping carts where the application has to associate data with a client.
Finally, in Chapter 14, we took a look at caching state so as to avoid unnecessary round-trips to a data source. Loading data from memory is usually much faster than loading it from a database or regenerating it. When it comes to storing data that all parts of your application can use, the data must be stored somewhere else besides view state and session state. We saw that the cache is available from virtually anywhere in the application via the HttpContext object. The HttpContext includes a reference to an instance of the HttpApplication object. In addition to being a holding place for the cache, the application object has its own dictionary that serves as a useful place to hold data. It works in very much the same way the Cache does. However, there are some subtle yet important differences between the Cache and the dictionary held by HttpApplication.
Keeping a dictionary and a data cache available for the rest of the application isn't the only good reason to implement a central application object. The other reason is to have a mechanism for handling application-wide events. We've seen that the Page class handles events for a request specifically. However, think about how the entire ASP.NET pipeline works. Some useful events aren't part of the page processing or request processing mechanism. Implementing those involves code working outside the normal page processing mechanism.
For example, we looked at session state in Chapter 13. When a request first comes through a site whose session state is enabled, when should the session object be set up? Certainly, you want it set up before the page-specific processing begins. In Chapter 10 we saw the ASP.NET security model. When should authentication and authorization be handled? You want those things to happen outside the context of the normal request processing, too. A final example is output caching, as we saw in Chapter 15. For output caching to work, ASP.NET needs to intercept the request when it first enters the pipeline so that it may bypass the whole page creation process and render the cached content instead.
ASP.NET's HttpApplication object can manage these sorts of things. When running, the Http-Application object represents a rendezvous point for all the parts of your entire Web application. If you're looking for software patterns to identify within ASP.NET, the HttpApplication most closely represents the singleton pattern. You treat it as a single instance of an object within your application. A reference to it is accessible at any point in time through the HttpContext class via the Current property.