Maintaining State: Persisting Values Between Round-Trips

Because a page and its controls are regenerated each time the page makes a round-trip, the state of the page isn’t preserved—that is, the value of its members is lost. This is a particularly subtle concept that’s hard to get used to when you first program with Web Forms because it’s so different from Windows Forms. Imagine that you have a page in which you’ve created a member to keep a count of the number of times the user clicks the Sumbit button. In a Windows Form, you initialize the variable at form load and then increment it whenever the user clicks the button. In a Web Form, the page, and thus the member you’ve created, is reinitialized each time the user clicks the button. You can increment the variable in the button click handler, but the value is never higher than 1.

Actually, the Web Forms page architecture does help you out somewhat. The page includes a property named ViewState. One of the last things a control does during page processing is store all the nondefault values of its properties in ViewState. The information stored in ViewState is rendered in the page as an HTML hidden field and is sent to the browser as part of the page. When the page is posted back to the server, during its initialization stage, the page reads the information back out of ViewState and plugs the values into the controls. The effect is that controls appear to be maintaining their state between round-trips.

However, if you create your own members during page processing, their values are not automatically saved in ViewState. If you need to persist values between round-trips, you have to do so yourself.

There are a couple of ways to persist state yourself. You can store values on the client by putting them in the page’s ViewState property and then reading them back out when the page is posted. In this scenario, you use the page itself to persist values. Cookies are another possibility for persisting values on the client.

Alternatively, you can persist values on the server. ASP.NET provides two server-based caches that you can use as shared memory for your pages. The first is session state, which is a temporary cache available to a particular browser session (making it user-specific). The second is application state, which is a cache that’s global to all pages in your application and to all separate users of the application. You can also use various .NET facilities to store values in a database, an XML file, a text file, or another storage medium available from server code.

No one strategy is best for all scenarios. Storing values in ViewState makes the page larger (and thus slower to load), which can affect performance if you store large values such as datasets. Storing values in ViewState is also less secure because users can see (and possibly modify) ViewState information. On the other hand, storing values in session or application state uses server memory. In particular, you need to use session state carefully because there’s a different session state for every concurrent user of your application.