Viewstate-a special storage container of ASP. NET

First of all, I'm not sure whether ASP. NET is the only one by viewstate or whether it has many features. I just think this is very helpful for the development of MVC separation in Web development.

The so-called viewstate is used to store the state of the view. Previous storage containers include cookies, sessions, applications, cache, and hidden. Sometimes, querystring used for variable transmission is also used as the storage container, but they are not used to store view-related information, however, because there is no place to store view-related information, people have to put it in disorder. Variables that are not afraid of expiration and expiration will be stored in the session and will not be lost across pages. When users access several other pages, they can restore the view on this page through the session. If you need to extend the time and there is not much data, you can put cookies, which is similar to session. The data is really short, and when the page is always submitted to itself, querystring can also be used as a way to save variables across the page lifecycle. If the page can be transmitted using only post without get, hidden is also a good choice, because the hidden capacity is large, and information is not left on the address. In ASP. NET, it is designed to be post (except for direct links) In most cases. Therefore, it is very suitable to Store View-related information with hidden.

Now that you can store them with hidden, why do you need unified management like viewstate? The most obvious reason is encryption. Viewstate is not the display or modification information for users. It is only because the view State will be lost between the page lifecycle, so we need to output the information to HTML and get it back when waiting for post, viewstate encryption (at least verification) ensures that the view is correctly restored. ASP. net built-in viewstate allows you to easily set the checksum and encryption, as long as you save the object that can be serialized, it can be automatically serialized and output to HTML, at the same time, the storage and restoration of this object are related to the control name and the position in the control tree, just like ASP. other features of the. Net control ensure that the data of the same ID control in different locations in the tree is not obfuscated. In short, viewstate is the best container for storing variables related to the cross-page lifecycle, but it cannot be called a session variable container across the out-of-page range (it should be the responsibility of the session ), therefore, it truly matches the State whose name is used to save the view.

There are many ASP. net beginners do not know the purpose of viewstate, think it is ASP. net internal objects, usually only use the set of public objects ASP, it will bring a lot of trouble. For example, there are two pages: grida and gridb. Click an entry to View Details and go to the details page. At the same time, the details page must provide a way to return to the original page (including the pages browsed by the original gridview ). How do I store the status of the original page, including the page from grida, gridb, and the page where the original gridview is located? Someone chooses to use querystring to pass it to the details page, so that the status will be passed back through querystring when the details page constructs the return link. Obviously, the original page status is not the query (query) of details, so it is not appropriate to pass the query string to the details page. Some people also choose to use session for transmission, but this state is only used for one transmission. Is it true that I can say a sentence to you as a session )? Of course not. Using hidden is a method, but based on the improvement of viewstate on hidden, viewstate should be used as the storage method of view State of grida or girdb, and restore it after the result is returned on the details page. It must be noted that only ASP. NET 2.0 supports cross-page PostBack internally. ASP. NET 1.x does not support cross-page PostBack, and viewstate cannot be accepted or maintained across pages.

The last thing to note when using viewstate is. Excessive viewstate usage is of course inefficient, but this does not cause a vulnerability for the correctness of website data. What really causes this vulnerability is the duplicate name of viewstate. Didn't viewstate be saved Based on the Control tree location and Control ID, so it won't be renamed again? This is true when the tree is static, but if the fruit tree is dynamically created, and the ID may be used repeatedly in different semantics, this may damage the correctness of the data. For example, a datacontrol sub-control is automatically named control_1, control_2, control_3, etc. If the datacontrol is databind again after the PostBack, The datasource may have changed, therefore, you need to clear all child controls and create them again based on datasource. Do not forget to call the clearchildstate method to clear both viewstate and controlState of the child control, otherwise, when you re-create the child controls and their names are control_1, control_2, and control_3, the original viewstate may be loaded back.