ne of ASP.NET's main improvements over classic ASP is its improved options for state management. Die-hard ASP classic developers moving to ASP.NET are often surprised by the dramatic change in programming paradigm. The powerful state management techniques in ASP.NET make Web development much more like traditional Windows desktop programming. This article shows you how to use the various techniques for managing state in ASP.NET and the pitfalls of each method.
Managing State the ASP.NET Way
The simple application shown in Figure 1
illustrates how ASP.NET manages state:
|Figure 1: The application retains the text in the label between postbacks to the server.|
The dropdown list and the button shown in Figure 1
are part of an HTML form. When the user clicks the Submit button, the browser posts the form back to the server. Forms in ASP.NET (aspx) pages post back to the originating page by default. The server-side code takes the item the user selected and uses it to create the text of a Label control on the Web page that shows the item selected. ASP.NET's automatic state management preserves the text in the Label control between postbacks as well as the user's selection in the Listbox. You don't have to write any extra code to make the items retain state between postbacks.
In contrast, using classic ASP, even a simple application such as this requires several lines of additional codes to ensure that the Listbox item remains selected and to preserve the text in the Label control. You have to write the additional code because HTTP is a stateless protocol. The Web server treats each request as a new connection; the server "forgets" about all requests immediately after processing them. In other words, in classic ASP, unless you write the state management code yourself, after each postback the user's Listbox selection will be lost (reset to the first item).
In ASP.NET, the list box is a Web server control
. Web server controls can automatically maintain their state and you can manipulate them on the server programmatically. That change has far-reaching ramifications for how you should think about state management in ASP.NET. To have a better understanding of how ASP.NET manages the state for you, take a look at the source for the page shown in Figure 1
<!-- partial page source -->
<form name="Form1" method="post"
<input type="hidden" name="__VIEWSTATE"
The preceding code shows a part of the HTML generated by ASP.NET. The HTML contains a hidden field called Viewstate that holds a string of characters. That string stores the state of the various controls on a Web Form. When the server processes a Web Form, it hashes and stores the state of the controls in that form in the Viewstate hidden field before it sends the page to the browser for display. When the browser posts the form back to the server, ASP.NET reads the values stored in Viewstate to restore the state of the controls. It is important to understand that Viewstate maintains information that would not normally be posted back to the server
. For example, in the sample application, the HTML form would automatically post the item selected by the user back to the server, but would not post back the text in the Label control. So there's no point in Viewstate storing the item selected, because it can restore the selected item from the information posted by the form. Hence Viewstate stores the text in the Label control but not the item selected.
You can examine what the form sends to the server by using the GET method instead of the POST method. Simply change the method
property of the form from post
. Now when the form is submitted, you can examine the URL to see the form data sent back to the server:
<!-- this code appears all one line -->
Click on the Submit button a few times and note how the length of the Viewstate parameter value increases!