The ViewState property

By default, the .NET Framework makes Web pages act like a standard Windows application by automatically repopulating the property values of server controls whenever the client forces a round-trip to the Web server. If your developers write Web applications by dropping server controls (instead of HTML control) on their Web forms, you’ll get this feature without having to write any code, unlike an Active Server Page. Of course, this functionality doesn’t come without a price—and it's paid in performance.

ViewState and the .NET Framework
The .NET Framework saves server control values by placing them in a hidden form field when the page is sent to the client. You can determine whether you want values saved between round-trips by manipulating the EnableViewState property. The page and all the controls on it inherit from the base Control class, which includes an EnableViewState property that determines whether the framework should automatically save the values of the page and the controls prior to rendering the page.

When the client posts the page, the Framework uses the ViewState to restore the control values before processing page-level events. You can use ViewState to save values other than control state. Any time a page is designed to post back to itself, you can use ViewState to store your own page-specific values across round-trips with simple syntax like this:

' Visual Basic
ViewState("name") = "Bob"

// C#
ViewState["name"] = "Bob";

There's good news and bad news
The good news about ViewState is that it doesn’t require any server resources. Rather than using expensive server-side session variables, all of the information necessary to repopulate the page or variable values necessary to process data on a particular page is automatically persisted in a structure within the page code itself. If you look at any page generated by the Framework with ViewState enabled, you’ll see a hidden field on the form named __ViewState that contains a stream of seemingly random characters. The Framework automatically hashes, compresses, and encodes ViewState values, giving you a higher level of security than you’d get if you implemented your own page persistence mechanism using HTML standard hidden fields. By combining ViewState for operations within a single page and QueryStrings for passing data between multiple pages, you can design a system that doesn’t require any server-side session variables or any client-side cookies.

The bad news is performance. Without proper management, you can create complex, slow-loading pages with lots of unnecessary page and control values passed between every page postback. You can turn tracing on to see the amount of the page attributable to ViewState. The tracing report includes a section detailing all of the control and page variable values that are currently being passed in the ViewState hidden variable.

As an architect, you should not only educate developers on the advantages of using ViewState, but also make specific recommendations for when they should turn it off.

ViewState performance recommendations
Here are a few performance recommendations for using ViewState:

Never save ViewState for a page that will not be posted back
Make sure you have ViewState turned off for static pages or pages with simple controls primarily designed for site navigation. It also makes sense to turn off ViewState for login forms. Even though the postback will occur, you will either process the ID and password and transfer to a new page or force the user to reenter the ID and password from scratch. The control values don’t need to be saved. You disable ViewState for an entire page with the @Page directive:

<%@ Page="" EnableViewState="false" %="">

Don’t save server control values that will be repopulated on each round-trip anyway
For example, if you’ve bound a server control to data coming back from a database with each new postback, then there’s no reason to save the values in ViewState when you send the page to the client. Unless you’re going to use the Datagrid as an input form, you should always disable ViewState as follows:

If performance is your main design goal, change the default Rather than building pages that rely on ViewState and then going back in and rewriting code to remove the dependency later, you can set a corporate standard to disable ViewState at the page level for all new pages and then turn it on selectively to achieve specific design goals. Some architects I know require ViewState off by default on all Internet pages but allow ViewState on by default on all intranet or internal Web application pages.

ViewState can work for you
Now that the .NET Framework implements a complete event framework around Web applications, architects can design more interactive user interfaces and put standards in place for when developers should use them. The ViewState is just one example, allowing page data to be stored between round-trips to the page.