Viewstate Optimization Strategies in ASP.NET (1/3)

[next]

Viewstate Optimization Strategies in ASP.NET

By Utpal Chakraborty ([email protected])

Like many features that are available in Microsoft's products, page viewstate in ASP.NET works behind the scenes by default. However, unlike most other features viewstate can impact the pages we develop dramatically. The impact may not only be in page size but also in server side performance. Pages with large viewstate can throw unexpected errors. It is important for us to understand what factors affect page viewstate and the strategies we can follow to gain maximum benefit from this feature. Since there is no one strategy for all scenarios, we will review two different scenarios separately.

Before we do that, we need to understand the motivation and benefits of viewstate. The Web is a stateless scenario. In the ASP world, developers often use hidden form fields to store values to persist information across post backs. Automatic state management is a feature that enables server controls to re-populate their values on a round trip without requiring you to write any code. However, this feature is not free since the state of a control is passed to and from the server in a hidden form field. Each control defines what it needs to store in its viewstate. It is stored as key-value pairs using the System.Web.UI.StateBag object. On page post back this data is sent back to the server and ASP.NET uses it to construct the state of the controls on the page during page initialization.

Viewstate can be controlled at four levels--the machine level, the application level, the page level and the control level. Each level inherits the setting of the level above by default. For viewstate to be enabled all four levels must enable viewstate. By default it is enabled at each level. If viewstate is disabled at the application level (this is done in the web.config file) it overrides any page level setting. Similarly, if viewstate is disabled at the page level then it overrides the setting of any control within the page. A child cannot override the viewstate setting of the parent. For example, if a page level viewstate setting is set to false, controls within the page cannot store viewstate information.

Only controls contained within a <form runat=server> tag in the .aspx page can store viewstate. A form field is required so the hidden field that contains the viewstate information can post back to the server. It must be a server-side form so that the ASP.NET page framework can add the hidden field when the page is executed on the server.

The page itself saves about 20 bytes of information into viewstate. This is used to distribute post back data and viewstate values to the correct controls on post back. So, even if viewstate is disabled for the page or application, you may see a few remaining bytes in viewstate. In cases where the page does not need to post back at all, viewstate can be completely eliminated from the page by omitting the server side <form> tag.

A key thing to remember is that viewstate for every control on every page is enabled by default. Since many server controls defined on a page contribute to viewstate size, viewstate if unchecked, will grow really large and impact performance.

To develop our strategy we need to understand how the various server controls affect viewstate. While it would not be possible to delve into the details of each of the server controls, for present purposes they can be classified into two groups.

The first group, the light control group (figure 1), consists of the controls that have very little or no effect on the viewstate of a page. So for all practical purposes the enable viewstate setting of these controls can be ignored. The validation controls also fall in this group. Most of these controls (notably, TextBox and CheckBox) retain their states irrespective of their viewstate settings. Thus, their viewstate can be turned off globally. One easy way of doing this would be to create a custom control that inherits from TextBox (say) and sets the viewstate property to false in its constructor as shown in the code below. This control can be used in place of the TextBox control throughout. It is necessary to disable the viewstate in the constructor (and nowhere else) since that way it can always be overridden on the page the control is being used using the enableviewstate attribute. This is good strategy to follow in almost every scenario.

using System;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.ComponentModel;
namespace ViewState.Controls
{
	public class MyTextBox : System.Web.UI.WebControls.TextBox
	{
		public MyTextBox()
		{
			base.EnableViewState = false;
		}
	}
}

The second group, the heavy control group (figure 2), consists of all the list and grid controls. Typically, these store their entire contents in the viewstate. Thus, all our efforts henceforth should concentrate on how best to manage the viewstate of these controls.

[next]

Created: November 20, 2002
Revised: November 20, 2002

URL: https://webreference.com/programming/asp/viewstate/