| Because HTTP is an inherently stateless protocol, you must use special techniques when you want to preserve information about users as they move from one page to the next or when they leave and reenter your application. Saving this information is known as saving or maintaining state . Why do you need to maintain state in the first place? The reason is that it can improve the user's experience with an ASP.NET application. By maintaining state, you can maintain the continuity between pages and between sessions that users demand of a web-based application, such as keeping track of items in a shopping cart or noting viewing preferences. You can also significantly enhance the performance of heavily used applications by making commonly used data available to any user , without making repeated trips to a database. You can preserve information at the application, session, and page levels of an ASP.NET application. The recipes in this chapter demonstrate how each is done: -
- Application state
-
By making commonly used data available to all users of an application, you can often improve application performance. Recipe 6.1 shows how to retrieve data from a database and place it in the Application object, thereby making it accessible to all users of an application. This is known as maintaining state at the application level. -
- Session state
-
Experienced web users expect you to remember who they are for the duration of their sessions at your site. Preserving this information, as well as information about their activities, is known as saving session state . Recipe 6.2 shows how to use an object to provide a container for some simple personalization data that is used by many pages of an application. The advantage is that you can maintain information for each user without having to access the database each time the data is needed. -
- Page state
-
Saving page state involves storing small bits of page information in hidden text fields or in the ViewState . For instance, Recipe 6.3 shows how a page with multiple states can remember the current state value between postbacks . In this instance, information is stored in a hidden field each time a page is submitted to the server so that the state can be restored on return to the client. In the chapter's last example, page state is used to store a complex object in the ViewState for tracking state information between page submittals. The example also demonstrates how you can emulate two-way data binding, which is available in Windows forms applications but not in ASP.NET applications. With two-way data binding, any changes made to the data in the bound controls are automatically updated in the underlying data container, making updates to the original data source extremely simple. In web forms, because the connection to the underlying data container is broken when the page is rendered, a bit of additional work is required to update the original data source, which the recipe shows you how to do. Finally, before we move onto the recipes themselves , it is worth mentioning the origin of the application and session states. Classic ASP developers will recognize in their naming the ASP intrinsic objects Application and Session . Indeed, an Application object is used in classic ASP to share information among all users of a given application, while a Session object is maintained for each user that requests a page from an application. Their uses remain essentially unchanged in ASP.NET, although their implementation is considerably more elegant and easier to work with using ASP.NET's classes, properties, and methods , as you will soon see in the recipes that follow. |
