Sunding asp.net3.5 Control and Component Development Technology Series-page state mechanism (i)

Content of this chapter

6.1 Page Status Overview

6.2 View State mechanisms

6.3 Control state Mechanism

6.4 Relationship between view state and control state

6.5 Encrypted page status

6.6 Clear Page Status

6.7 View state analysis of dynamically added controls

6.8 Custom type converters for efficient serialization

6.9 Page State Performance optimization strategy

6.10 Summary of view state and control state

6.1 Page Status Overview

In ASP. NET technology in the server processing mechanism, the server each processing the client's request that the task is over, when the client requests again, the server will be as a new request processing, even the same client. In other words, the server will not save some of the two requests between the forward and backward data, which is often a developer to achieve a link between the operation is more cumbersome, such as input some information into a text, and then submit a button, Most of the time we have to deal with the server-side events submitted by the button to process the data before submission and submit the button when the user entered the most recent data, that is, want to get the text box both the old and new values, but the server does not save the previous request of any information, then how to do

Data correlation between two times page requests, ASP. NET is implemented through the view mechanism, simply speaking, the View area information (ViewState) is stored in a hidden field on the page (named __viewstate, except that the values in view state are hashed and compressed and encoded for the Unicode implementation, It is more secure than the hidden domain control we set ourselves, and every time a view mechanism is stored in this field, it is passed back and forth in the form of "client to server", and when processing is complete, Finally, the newly processed results are stored as new viewstate in the hidden fields on the page and returned to the client along with the content of the page.

The view mechanism supports many types of data storage, the basic types of which are strings, numbers, Boolean values, colors, dates, bytes, arrays of various types, and so on. The view mechanism has been optimized for some types of objects such as ArrayList and hash table collections, except for the basic type view state view mechanism, which also supports custom types, because the viewstate data is stored as a serialized format string, so the. NET is used by default. The framework provides binary serialization to serialize objects, and for some of the more complex objects, a specialized type converter typeconvert serialization is typically used, rather than by default. NET provides a resource-saving binary serialization. The implementation of the Typeconvert class has many examples in the 4th chapter, followed by a description of the type converter applied to view state and an example.

To improve performance, you typically disable the page or disable the status view of the server-side controls, and some controls do not need to maintain their state, such as a label control that only displays text, and the text of the label, the value does not participate in the postback, you can set its properties: Enableviewstate=false;

If the entire page control does not need to maintain a status view, you can set the status view of the entire page to false:<%@ page enableviewstate= "false"%>.

Because of the view state used inside the control, this can result in the view state being invalidated and even a fatal problem-the control cannot be used. To illustrate, disabling a view is legal, and a good control should allow view state to be disabled by the developer as appropriate and still run correctly.

To solve this problem, ASP.net 2.0 supports the control state mechanism. The state data of a control can now be persisted through control state instead of view state, and control state is not allowed to be disabled. control state is appropriate when you need to save logic between controls, such as a tab control that remembers the index Selectindex that is currently selected at each postback. Of course the ViewState property fully satisfies this requirement and the custom control does not run correctly if view state is disabled. Control states work in exactly the same way as view state, and they are stored in the same hidden field by default on the page.

To sum up, general developers use the ASP.net view mainly in the following three ways: