Preliminary study on ASP.net ViewState (1) from MSDN

Preliminary study on ViewState of ASP.net asp.net
Susan Warren.
Microsoft Corporation
November 27, 2001

When talking to developers who have just contacted the ASP.net page, the first question they usually ask me is: "What is that ViewState?" "The feeling in their tone was like when I came to an exotic restaurant where the waiter served a dish I had never seen before--both puzzled and curious. But someone must think it's good, otherwise it won't be offered. So I'll try it first, maybe I'll like it, even though it does look weird!

The same is true for ViewState, but if you adapt to its style, you'll find that in many cases you'll be happy to use ViewState in your own asp.net application because it helps you do more work with less code. However, there are times when the ViewState is completely abandoned. Here we will explain the two cases separately, but let us first answer what is ViewState this question.

Answer: ViewState is used to maintain the UI state of the page
The Web is stateless, asp.net pages are not stateful, and they are instantiated, executed, rendered, and processed during each round trip to the server. As a Web developer, you can add states by using well-known techniques, such as storing the state on a server in session state, or uploading a page back to itself. The following is an example of the registered form in Figure 1.



Figure 1: Restoring the Return form value

As you can see from the image above, I have chosen an invalid value for the light meal. This form is as friendly as most forms on the Web, and it displays a useful error message and an asterisk next to the field where the error occurred. Also, the form shows all the valid values I entered in the other text boxes and Drop-down lists. This is possible in some way because HTML form elements send their current values from the browser to the server in the HTTP header. You can use ASP.net tracing to view the form values that are returned, as shown in Figure 2.



Figure 2:http The return value in the form (shown by asp.net tracking)

Before ASP.net, restoring values to form fields through multiple postbacks is entirely the responsibility of the page developer who will have to pick up the pass-through from the HTTP form and push it back into the field. Fortunately, ASP.net can now automate this task, eliminating a tiresome job for developers, and no need to write a lot of code for the form. But this is not ViewState.

ViewState (English) is a mechanism that asp.net use to track server control state values, otherwise these values will not be returned as part of the HTTP form. For example, the text displayed by a Label control is saved in ViewState by default. As a developer, you can bind the data, or set the label programming only once for the first time the page is loaded, and the label text will be automatically populated from the ViewState in subsequent back crosses. Thus, in addition to reducing tedious work and code, ViewState often reduces the number of round-trip times to the database.

The working principle of ViewState
ViewState is really no mystery, it is a hidden form field managed by the ASP.net page framework. When ASP.net executes a page, the ViewState value and all controls on the page are collected and formatted into a coded string, which is then assigned to the Value property (that is, <input type=hidden>) of the hidden form field. Because the hidden form field is part of the page that is sent to the client, the ViewState value is temporarily stored in the client's browser. If the client chooses to pass the page back to the server, the ViewState string is also returned. In Figure 2 above you can see the ViewState form field and its return value.

After the postback, the asp.net page frame resolves the ViewState string and populates the ViewState property for the page and individual controls. The control then uses the ViewState data to revert itself back to its previous state.

There are three small issues worth noting about ViewState.

If you want to use ViewState, you must have a server-side form marker (<form runat=server>) in the ASPX page. form fields are required so that hidden fields containing ViewState information can be passed back to the server. Also, the form must be a server-side form, so that the ASP.net page frame can add hidden fields when the page is executed on the server.
The page itself stores about 20 bytes of information in ViewState, which is used to distribute postback data and ViewState values to the correct control at the time of the postback. Therefore, even if the page or application disables ViewState, you can still see a small amount of remaining bytes in ViewState.
When the page does not return, you can remove the ViewState from the page by omitting the server-side <form> tag.
Make full use of ViewState
ViewState provides a magical way to track the state of a control across the postback because it does not use server resources, does not time out, and is applicable to any browser. If you're writing a control, you'll definitely need to know how to maintain state in the control (in English).

Developers can also use ViewState in almost the same way when they write pages, but sometimes the page contains UI state values that are not stored by the control. You can track values in ViewState, and the syntax for using the programming syntax for sessions and caching is similar:

[Visual Basic]
' Save in the ViewState
ViewState ("SortOrder") = "DESC"

' Read from ViewState
Dim SortOrder as String = CStr (ViewState ("SortOrder"))

[C #]
Save in ViewState
viewstate["SortOrder"] = "DESC";

Read from ViewState
String sortOrder = (string) viewstate["SortOrder"];