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. You need to maintain state to 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 webbased application, such as keeping track of items in a shopping cart or noting viewing preferences. You can enhance the performance of heavily used applications by making commonly used data available to any user, without making repeated trips to a database.
Be aware, however, that maintaining state can sometimes result in a decline in performance. For example, if you place large objects in session state you can negatively affect an application's performance by tying up system resources.
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:
By making commonly used data available to all users of an application, you can sometimes improve application performance. Recipe 7.1 shows how to retrieve data from a database, place it in the Application object, and make it accessible to all users of an application. This is known as maintaining state at the application level.
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 7.2 shows how to use an object to provide a container for some simple personalized data that is used by many pages of an application. The advantage is you can maintain information for each user without having to access the database each time the data is needed.
Saving page state involves storing small bits of page information in hidden text fields or in the ViewState. For instance, Recipe 7.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 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 demonstrates how you can emulate two-way data binding with the DataGrid, a capability that is native to the GridView control (see Recipe 2.16) but not to the DataGrid. 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 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.