ASP.NET pages and controls can store some state variables into a persistent medium known as the ViewState. Whatever value you place in the ViewState is guaranteed to survive across requests. Typically, server controls use the ViewState to cache the values of some of their properties. For example, the textbox control stores to the ViewState, and retrieves from it the current value of properties such as ReadOnly, MaxLength, and Text. Each and every control sees its own ViewState object and uses it as a general-purpose cargo collection. When the page is rendered to HTML, though, the contents of all view states of all controls in the page is flushed into a single object. This object is then serialized to a binary format, encoded to Base64 and copied to a hidden field.
When the page posts back, the ASP.NET runtime retrieves and decodes the ViewState and uses its values to reinitialize the various controls on the page. In other words, the ViewState represents the state of the page the last time it was served on the server.
So far, so good. The rub with the ViewState lies in the fact that it adds a significant burden to any page served to the browser. For complex ASP.NET pages, the extra overhead of the ViewState can easily reach 10 KB. Not only do you risk downloading an oversized page, but the extra bytes stored in the ViewState are completely useless on the client. More, if you modify the ViewState on the client side, the page will throw an exception once returned back to the server.
To keep your page lean and mean, you can disable the ViewState throughout the page or just for a few controls. Most ASP.NET controls can do without the ViewState even though this requires some adjustments in the programming style. Some controls, though, just can't do without the ViewState. Technically speaking, the ViewState is not a strict requirement for ASP.NET controls. In practice, some controls need to persist data across postbacks, and nonpersistent data would result in a loss of functionality. For example, the TextBox control can't raise the TextChanged event if the ViewState is disabled. The TextChanged event is fired in response to a detected difference between the new and the old value of the Text property. But if the old value is not cached, there's no way for the control to detect the difference.
Originally, the ViewState was introduced as a way to let applications store dynamic data between one or more requests. It was not designed to be a sort of control-state container. A couple of years of real-world experience proved two key things. One is that disabling the ViewState may break the code because some controls stop working the way you are accustomed to. Secondly, ASP.NET controls do need a mechanism to persist their control state. Obviously, control developers need an alternative to the ViewState for storing the state of a control.
Until ASP.NET 2.0 bring some good news on this topic, there's one neat and elegant workaround for the issue-—using a sort of "parallel" ViewState. Create a control-specific collection in which you store all the values you want to persist. Next, when the control is about to render, you serialize the contents of this collection to a hidden field. The content of the hidden field will be retrieved and processed when the page posts back during the preloading step of the page. A good place to rebuild the control state is in the LoadViewState override.
Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant
based in Rome, Italy. Dino is a contributing editor to Windows Developer
Magazine and MSDN Magazine, and the author of several books for Microsoft
Press including Building Web Solutions with ASP.NET and ADO.NET
and Applied XML Programming for .NET. Contact Dino at [email protected]