ASP.NET State Management in ASP.NET 2.0
In this tutorial you will learn about new features included in ASP.NET 2.0 for State Management. The Control State, differences in handling View State and Control State, Implementing the control state. Initialization and loading of a controls private state.
Web pages are constantly constructed and destroyed with round trips to the server. However, state maintenance is an essential aspect of deploying web pages on a stateless protocol such as HTTP. State management is defined as a process of maintaining state and page information over multiple page requests.
State maintenance could be a feature of a client side or a server side process. The approach to state maintenance within an application will depend on a number of factors such as sensitivity of data, storage of data, performance goals and so on. ASP.NET 2.0 state maintenance can be enforced from both the client and the server effectively.
On the client side the developer has options of View state, hidden fields and cookies. The ViewState property provides a dictionary object for retaining values between multiple requests for the same page. The Hidden field stores a variable in its value property and is explicitly added to the page. The HTMLInputHidden control provides the hidden field property to the page. A cookie is a small amount of data that is stored in the client machine or in the memory of a client browser session. It contains site specific information that the server sends to the client along with a page output. Cookies can be temporary or have specific expiration dates. Client side storage would imply weakened security and a limitation on the amount of data that can be stored but better performance.
The server side options would include Application, session and Cache. Application state is a key value dictionary structure that is created during the page request to a URL. Application specific information can be added to this structure and stored between page requests. The session state is scoped to the current browser session and the number of session states will be determined by the number of users using the application. The session can be different for each visit by the user. The Cache is a hashtable used to store frequently accessed data. It is global to the application and is visible from within each currently active session. The Cache can be accessed using the name/value properties. While session is a block of memories set aside for each user, cache manages globally accessible data. Server side storage would provide for greater security but would have issues of scalability if size of information is large.
The entire state management therefore, will have to be a balance between security and performance.
ASP.NET 2.0 has introduced several new features to help the developer.
1. Custom controls with Control state which are more reliable than View State. This control is independent of the view state and customizable.
2. Custom session state management options which are persistent in the data storage medium and a session state provider object can be created.
3. Mechanism for handling custom cache dependencies, including SQL Server database dependencies in with a feature to invalidate cache results when one of the records displayed gets updated.
The control state
All controls in ASP.NET inherit the View State property from the Control Class. The state is stored in Name/value pairs and the view state property returns an instance of the StateBag class which is a specialized dictionary object. At a level of abstraction the Control state and the View state are similar but have several differences in handling.
|
View State |
Control State |
|
View state is a property inherited from the control class and is inherited by all controls. It is independent of the Control’s state. |
Control state is the control’s private view state. Control state is designed for storing a control’s essential data (such as the page number of a pager control) that must be available on postback when view state is disabled. |
|
View state can be enabled or disabled for an entire page or for a specific control |
Control state cannot be disabled for a control. |
|
View state is sent by the server as a hidden variable in a form, as part of every response to the client, and is returned to the server by the client as part of a postback. However, to reduce bandwidth demand when using mobile controls, ASP.NET does not send a page’s view state to the client. Instead, the view state is saved as part of a user’s session on the server. Where there is a view state, a hidden field that identifies this page’s view state is sent by the server as part of every response to the client, and is returned to the server by the client as part of the next request. However, since the view state for a given page must be kept on the server, it is possible for the current state to be out of synchronization with the current page of the browser, if the user uses the Back feature on the browser to go back in the history. |
The control state is stored in the same hidden variable as the view state. Even when view state is disabled control state travels to the client and back to the server in the page. On postback the hidden variable is deserialized and the control state is loaded into each control that is registered for the control state mechanism. |
|
The custom control’s view state is stored by adding to a dictionary object through the ViewState property which is inherited from the Control Class. The ViewState property returns an object of the type StateBag which is a dictionary like type. |
In the control state the objects are not stored in a fixed container. The data can be maintained in plain private or protected members. This makes access to data faster and is not mediated by a dictionary object. |
|
Few server controls make private use of the view state and even in those controls the use is limited to specific features. |
All controls can use the control state as it is intrinsic to the control. |
|
If a developer wants a control to persist in its state between posts, the view state has to be used privately to store the content of non public properties. However, this will not work if the view state is disabled or the application or page level settings are changed. |
The control state replaces the private use of the view state by storing the state within the control. |
|
It is possible to control the amount of data that is moved back and forth between posts. |
It is not possible to control the amount of data that is moved back and forth during posts. |
|
The view state of the control/page is automatically initialized and restored by ASP.NET runtime |
The developer has to initialize the private state of a control on loading. |
.
.
Implementing the control state:
The implementation of the control state is prerogative of the programmer. The process may be as complex as implementing serialization and deserialization for the control’s state or a mere tweaking of the control’s code to achieve optimal performance in the context of usage. The initialization and loading of a controls private state has to be done in three steps:
- Override the OnInit method and invoke the System.Web.UI.Page.RegisterRequiresControlState(System.Web.UI.Control) method to register with the page for participation in control state.
- Override the SaveControlState method to save data in control state.
- Override the LoadControlState method to load data from control state.
Let us assume that we want to create a button called IndexButton. The custom control saves its state both in the control state and the view state. The IndexButton derives from the Button class and defines an Index property that is saved in control state. The IndexButton also defines an IndexViewState property that is stored in the ViewState dictionary.
Click here to view sample code
Now let us test this in the default.aspx page. Let us disable the view state by setting the EnableViewState attribute of the page to false in the page directive. In the Page_Load event handler let us add the value of the Index and IndexInViewState property in the IndexButton control. It must be noted that since the Index property is stored in the control state(and cannot be disabled), it maintains its value on postback and increases by one each time the page is posted back to the server. Since the IndexViewState property is stored in the view state and is disabled for the page, the IndexViewState property is always zero.
Click here to view sample code
New data structures can be allocated (arrays of objects, a hashtable or a custom type) and filled with the private properties to persist across the postbacks. When the method terminates it returns this object to ASP.NET runtime. The object is then binary serialized and encoded to a Base64 stream. It follows the class used to collect the control state properties must be serializable.
It is clear that the control state features were introduced to avoid the common errors made by programmers in control development. In the next section we shall examine the session state and how it has been extended in ASP.NET 2.0.
