How do I decide what to store in viewstate?

Question

I have been writing a bunch of generic ASP.NET controls, and one thing I can't seem to wrap my mind around is when to store values in viewstate, and when to assume it's OK not to.

On one hand, it makes sense to store the entire state of the control in viewstate, including properties like:

• Text box values entered by the user (or any form data)
• Configuration options like height or page size
• Even how the control has been composed - for example storing all the data a grid view is built from, or the grid itself.

Ignoring performance, the more you can shove in viewstate the better, because it means the control will behave exactly the same across postbacks and never "accidentally" revert a value or "forget" it was disabled. But viewstate is not free. Storing everything means the control will now output both the HTML and all its internal properties to create that HTML, which would almost always more than double the output.

My question is not about performance, but about strategy. On what criteria do I decide to put a property in viewstate? I was thinking something along these lines:

If the user can't change a property, then the server will always set it explicitly, so it's OK to leave it out of viewstate. Even for something like color=red, the user doesn't set this property directly; they will click a button elsewhere which indirectly sets this property. That button or its owner should keep the state, not the control that renders the color red.

This logic implies that the only properties that should go into viewstate would be:

1. Form elements like <input> (and with Request.Form[c.UniqueID] this can be avoided still)
2. Properties that the user can control interactively directly on the control.

Does this logic make sense? It seems weak and I'd like to hear more from experts.

Answer 1

Use ViewState for things that are not necessary for your control to work.

Use ControlState for things that are necessary for your control to work even if ViewState is disabled.

The initial values and the control hierarchy(even html-controls) are compiled into Temporary ASP.NET Files when the page is first requested. So they don't need to be stored anywhere when they are never changed (and even ViewState will not save them).

A control does only store properties in ViewState which have changed during the page's life-cycle(since TrackViewState). A control which state was changed is "dirty". For example if you change TextBox1.Text in page_load, ViewState.IsItemDirty("TextBox1.Text") would return true. These values will be stored in ViewState.

Look here and here. (I really recommend to read both articles)

Control State vs. View State Example

Answer 2

Check this article on MSDN covering when, where and what to use the plethora of state management options available in ASP.NET the view state section is posted below for convenience - checking your requirements against the advantages and disadvantages should guide you on usage on a case by case basis:

Whole article here: http://msdn.microsoft.com/en-us/library/z1hkazw7(v=vs.100).aspx

Viewstate Excerpt:

View State

Web Forms pages provide the ViewState property as a built-in structure for automatically retaining values between multiple requests for the same page. View state is maintained as a hidden field in the page. For more information, see ASP.NET State Management Overview.

You can use view state to store your own page-specific values across round trips when the page posts back to itself. For example, if your application is maintaining user-specific information — that is, information that is used in the page but is not necessarily part of any control — you can store it in view state.

Advantages of using view state are:

No server resources are required The view state is contained in a structure within the page code.

Simple implementation View state does not require any custom programming to use. It is on by default to maintain state data on controls.

Enhanced security features The values in view state are hashed, compressed, and encoded for Unicode implementations, which provides more security than using hidden fields.

Disadvantages of using view state are:

Performance considerations Because the view state is stored in the page itself, storing large values can cause the page to slow down when users display it and when they post it. This is especially relevant for mobile devices, where bandwidth is often a limitation.

Device limitations Mobile devices might not have the memory capacity to store a large amount of view-state data.

Potential security risks The view state is stored in one or more hidden fields on the page. Although view state stores data in a hashed format, it can still be tampered with. The information in the hidden field can be seen if the page output source is viewed directly, creating a potential security issue. For more information, see ASP.NET Web Application Security and Basic Security Practices for Web Applications.