3.3 State Management
In a typical web page, it is very common for data entry forms to retain their values after the form has been posted and the same page is returned to the client (that is, to retain the values from a posted form in the postback). To implement this feature in classic ASP, you need to determine whether or not the page is requested by a client for the first time. You also need to write code that will display the submitted value in the controls. In contrast, ASP.NET performs state management automatically in postbacks.
ASP.NET uses a simple hidden HTML form field to retain the values automatically during postbacks. There are no ActiveX controls or applets or client-side scripts used to maintain state. Thus, you need not write code to retain values explicitly.
Now let's revisit the concept of ViewState, which was introduced earlier in this chapter. ViewState is a collection of information about the properties of an ASP.NET page and its controls (maintained in a hidden form field named _VIEWSTATE). Since control state on the server does not exist once the page has been rendered to the client, ViewState exists to store the value of properties of controls on the page. As the name itself implies, ViewState preserves the state associated with a particular view of a page. It is used by the noninput controls (such as Label and DataGrid) to store their ambient state across requests. Thus, when a page is posted back to the server, and the result of the postback is rendered to the browser, controls such as textboxes and listboxes will automatically retain their state, unless the control's EnableViewState property has been set to False or the state of the control was modified programmatically on the server.
If your page is not posted back to itself, you can set the property EnableViewState to False at the page level (via the @ Page directive) to avoid the extra processing and storage space required for maintaining ViewState. You can also disable/enable view state on a per control basis.