ViewState may be one of the most misunderstood concepts in ASP.NET. Though simple at first glance, the significance of ViewState is often overlooked, or completely misinterpreted when working with child controls, dynamically added controls or when developing custom controls. Dave Reed has written an article on Truly Understanding ViewState, that describes exactly how to plan ASP.NET control initialization and creation for all of these scenarios. Proper ViewState usage (and preventing improper usage) will keep page sizes smaller, leading to much greater performance and scalability for ASP.NET applications. For public sites built with ASP.NET, a large ViewState can also hurt search engine rankings.
Dave begins by clarifying exactly what ViewState does and does not do:
Dave begins by clarifying exactly what ViewState does and does not do:
WHAT DOES VIEWSTATE DO?
1. Stores values per control by key name, like a Hashtable
2. Tracks changes to a ViewState value's initial state
3. Serializes and Deserializes saved data into a hidden form field on the client
4. Automatically restores ViewState data on postbacks
Even more important than understanding what it does, is understanding what it does NOT do:
WHAT DOESN'T VIEWSTATE DO?
1. Automatically retain state of class variables (private, protected, or public)
2. Remember any state information across page loads (only postbacks) (that is unless you customize how the data is persisted)
3. Remove the need to repopulate data on every request
4. ViewState is not responsible for the population of values that are posted such as by TextBox controls (although it does play an important role)
5. Make you coffee