Programming Microsoft ASP.NET 4 - Dino Esposito [371]
But here I’m just throwing out numbers using a bit of common sense. If you can disable the view state altogether, do it. At the very least, you should avoid storing there the avoidable items that don’t change often and are easily cached on the server, such as a long list of countries/regions.
Programming the View State
By default, the view state is enabled for all server controls; however, this doesn’t mean that you strictly need it all the time and for all controls. The use of the view-state feature should be carefully monitored because it can hinder your code. View state saves you from a lot of coding and, more importantly, makes coding simpler and smarter. However, if you find you’re paying too much for this feature, drop view state altogether and reinitialize the state of the size-critical controls at every postback. In this case, disabling view state saves processing time and speeds up the download process.
Disabling View State
You can disable the view state for an entire page by using the EnableViewState attribute of the @Page directive. Although this is not generally a recommended option, you should definitely consider it for read-only pages that either don’t post back or don’t need state to be maintained.
<% @Page EnableViewState="false" %>
A little known aspect of view state programming is that, with the previous setting in place, all controls within the page have view state disabled no matter what their view state settings are. When view state is enabled at the page level, instead, disabling the view state on a control produces the effect of disabling it just on that control.
The net effect of this situation is that if you have 300 controls in a page and just want to have view state enabled on, say, three of them, all that you can do is disable view state on the remaining 297. To make up for this, in ASP.NET 4 a new property has been added to exercise stricter control over view state: the ViewStateMode property. The property accepts three values: Inherit, Enabled, and Disabled. If the value is Inherit, the control gets the setting of its parent. The ViewStateMode property takes precedence over EnableViewState.
Determining When to Disable View State
Let’s briefly recap what view state is all about and what you might lose if you ban it from your pages. View state represents the current state of the page and its controls just before the page is rendered to HTML. It is then serialized to a hidden field and downloaded to the client. When the page posts back, the view state—a sort of call context for the page request—is recovered from the hidden field, deserialized, and used to initialize the server controls in the page and the page itself. However, this is only the first half of the story.
After loading the view state, the page reads client-side posted information and uses those values to override most of the settings for the server controls. Applying posted values overrides some of the settings read from the view state. You understand that in this case, and only for the properties modified by posted values, the view state represents an extra burden.
Let’s examine a typical case and suppose you have a page with a text box server control. What you expect is that when the page posts back, the text box server control is automatically assigned the value set on the client. Well, to meet this rather common requirement, you don’t need view state. Let’s consider the following page:
<% @Page language="c#" %>
Apparently, the behavior of the page is stateful even if view state is disabled for a couple of controls. The reason lies in the fact that you are using two server controls—TextBox and CheckBox—whose key properties—Text and Checked—are updated according to the