ASP.NET ViewState Misconception

A very common misconception amongst ASP.NET page developers is that ViewState must be enabled to persist values across postbacks.

This is not true. Try this: on an .aspx page, add a textbox and a button. Your code should be similar to the one as follows:

Run the code, key in something in the textbox and click the button. As expected, the page is submitted to the server, and when it comes back, whatever you keyed in reappears in the textbox. Now, in the Design view, set EnableViewState to be false for the textbox. Run the code, and the text in the textbox is still persisted across postbacks. The result would be the same even if you add EnableViewState="false" in the .aspx Page directive.

This is because form data is saved in the Request object. After a page is posted back, ASP.NET reads Request.Form and populates the form with this data. So why bother with ViewState at all? ViewState is used to persist control properties and attributes across postbacks, such as the BackColor property.

Dino Esposito explains it quite clearly:

[T]he view state represents the state of the page and its controls just before the page is rendered in HTML. When the page posts back, the view state 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 half the story.

After loading the view state, the page reads client-side information through the Request object and uses those values to override most of the settings for the server controls. In general, the two operations are neatly separated and take place independently. In particular, though, the second operation—reading from Request.Form—in many situations ends up just overriding the settings read out of the view state. In this particular case the view state is only an extra burden.

Let's examine a typical case. Suppose you have a page with a textbox server control. You expect that, when the page posts back, the textbox server control is automatically assigned the value set on the client. To meet this rather common requirement, you don't need view state ... the behavior of the page is state-aware even if view state is disabled. The reason is that you are using two server controls—TextBox and CheckBox—whose key properties are updated according to the values set by the user. These values will override any setting that view state may have set. In short, as long as you're simply interested in persisting properties such as Text or Checked you don't have any need for view state.

So, if for some reason you need to override this default behaviour, in the codebehind, you need to set TextBox1.Text = String.Empty in Page_Load.

13 May 2008 | Software engineering, ASP.NET | Comments