A Short Synopsis of ASP.NET ViewState

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." --Martin Fowler
We often get questions about ASP.NET Session and ViewState. Some time ago I put together an FAQ about Session and it seems to be popular. So now, a short one on ViewState.

What ViewState Isn't:

ViewState does not restore posted values to controls on a WebForm.
If you disable a control's ViewState, you will see that its value is still restored.

ViewState does not automatically recreate any controls that were dynamically created in the code.
Dynamically created controls on a page must be recreated when the page PostBack is processed.

ViewState is not for user or session data or for transferring data across pages.
Viewstate only can store data that is sent back to the same page during a PostBack operation.

ViewState does not hold "Controls".
Viewstate does not normally hold entire controls - only values and properties.

What ViewState is:

Viewstate represents the state of the page when it was last processed on the server. ViewState is used to track and restore the state values of controls that would otherwise be lost, either because those values do not post with the form or because they are not in the page html. A control defined solely in your page html with no changes made in the code will have no ViewState. ViewState only holds the values of properties that are dynamically changed somehow, usually in code, data-binding, or user interactions, so that they can be restored on each request. ViewSate does not hold "controls", it only hold values and the ID's of the controls they belong to.

ViewState also provides a StateBag, which is a special collection or dictionary, for each page. You can use this to store any object or value, associated with a key, to retain across PostBacks in a manner similar to the way you would store an object in Session state. This is useful for custom items that are relevant to only that specific page instance, since these values will automatically post with that page, but will not transfer to any other pages. One custom use of ViewState is to keep track of any dynamically created controls, which you can then manually recreate on each post based on your tracking data in ViewState. You do NOT store the Control in ViewState - you store the selected or entered value.

ViewState Format:

ViewState is serialized via the LOSFormatter class, which is a lightweight version of the BinaryFormatter, automatically serialized to or from a Base64 encoded string, and passed across page PostBacks as a hidden form field, __VIEWSTATE. For more info on how LOSFormatter works, see this article.

ViewState is saved before rendering in the Page.SavePageStateToPersistenceMedium method and it is restored on PostBacks in the Page.LoadPageStateFromPersistenceMedium method. Both of these methods can be overridden to save ViewState to Session, Cache, a Database, or even the file system.

Each control's ViewState is stored in a Triplet (System.Web.UI.Triplet) with the first object being a Pair (System.Web.UI.Pair) (or an Array of Pairs) of ArrayLists of related name-values. The second object of the Triplet is an ArrayList of that control's child indices in control tree, and the third object is an ArrayList of the similar associated Triplets of those child controls. Paul Wilson has an article that goes into much more detail. If you are interested in experimenting further, Fritz Onion has put together a nice GUI viewstate viewer here.

Managing ViewState:

While developing a page, you can keep the size of the view state under control by enabling tracing on the page. Once you have set the @Page's trace attribute to true, look under the ViewState column of the control tree. This will give you a pretty good idea of what each control is doing. ViewState can be enabled or disabled on controls with the EnableViewState property.