Preliminary study on ASP.net ViewState
What the hell is ViewState?
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