Tell something about View State in Asp.Net

This is used by an ASP.NET Web page to persist changes to the state of a Web Form across postbacks.  The view state of a page is, by default, placed in a hidden form field named __VIEWSTATE. The load view state stage only happens when the page has been posted back. During this stage, the view state data that had been saved from the previous page visit is loaded and recursively populated into the control hierarchy of the Page. It is during this stage that the view state is validated.  It provide state to a webpage.


As we know A Web application is stateless. A new instance of the Web page class is created every time that the page is requested from the server. This would ordinarily mean that all information in the page and in its controls would be lost with each round trip. For example, by default if a user enters information into a text box on an HTML Web page, that information is sent to the server. However, it is not returned to the browser in the response.
To overcome this intrinsic limitation of Web programming, the ASP.NET page framework includes several state-management features to preserve page and control values between round trips to the Web server.

What Happens with View State

• Stage 1 - Initialization
• Stage 2 - Load View State
• Stage 3 - Load Postback Data
• Stage 4 - Load
• Stage 5 - Raise Postback Event
• Stage 6 - Save View State
• Stage 7 - Render

View state's purpose in life is simple: it's there to persist state across postbacks. (For an ASP.NET Web page, its state is the property values of the controls that make up its control hierarchy.). The ViewState property is defined in theSystem.Web.UI.Control class, meaning that all ASP.NET server controls have this property available. Nothing comes for free, and view state is no exception. The ASP.NET view state imposes two performance hits whenever an ASP.NET Web page is requested:

1. On all page visits, during the save view state stage the Page class gathers the collective view state for all of the controls in its control hierarchy and serializes the state to a base-64 encoded string. (This is the string that is emitted in the hidden __VIEWSTATE form filed.) Similarly, on postbacks, the load view state stage needs to deserialize the persisted view state data, and update the pertinent controls in the control hierarchy.
2. The __VIEWSTATE hidden form field adds extra size to the Web page that the client must download. For some view state-heavy pages, this can be tens of kilobytes of data, which can require several extra seconds (or minutes!) for modem users to download. Also, when posting back, the __VIEWSTATE form field must be sent back to the Web server in the HTTP POST headers, thereby increasing the postback request time.

Considerations for Using View State

View state provides state information for a specific ASP.NET page. If you need to use information on more than one page, or if you need the information to persist across visits to the Web site, you must use another method for maintaining state. You can use application state, session state, or profile properties. For more information, see How to: Pass Values Between ASP.NET Web Pages.

View state information is serialized into XML and then encoded by using base-64 encoding, which can generate large amounts of data. When the page is posted to the server, the contents of view state are sent as part of the page postback information. If view state contains a large amount of information, it can affect performance of the page. Test the performance of your pages by using typical data for your application to determine whether the size of view state is causing performance problems.

Another consideration is that if the amount of data in a hidden field becomes large, some proxies and firewalls will prevent access to the page that contains them. Because the maximum allowed amount can vary with different firewall and proxy implementations, large hidden fields can cause intermittent problems. If the amount of data that is stored in the ViewState property exceeds the value specified in the page's MaxPageStateFieldLength property, the page splits view state into multiple hidden fields. This reduces the size of individual hidden fields below the size that firewalls reject.

View state is enabled by default, but some controls on a page might not need view state. For example, if a control is refreshed from the data store on each postback, you can turn view state off for that control in order to reduce the size of view state.

You can configure controls so that view state is disabled by default for all controls within a page or a container control, and you can then enable view state for specific controls. You can also configure controls so that view state is disabled and cannot be enabled for child controls.

To disable view state for a control by default so that it can be enabled for child controls, set the ViewStateMode property of the control to Disabled. To disable view state by default for an entire page, set the ViewStateMode attribute of the @ Page directive to Disabled.

To disable view state for a control and its children so that it cannot be enabled for child controls, set the EnableViewState property of the control to false. To disable view state for an entire page and all of its child controls, set the EnableViewState attribute of the @ Page directive to false.

Control State

In addition to view state, ASP.NET supports control state. The page uses control state to persist control information that must be retained between postbacks, even if view state is disabled for the page or for a control. Like view state, control state is stored in one or more hidden fields.