Asp. NET state management to make you plainly

Programmers who develop winfrom may not care about maintaining the state of the application because the Winfrom itself is running on the client and can maintain its application state directly in memory. However, the ASP. NET application runs on the server side, and the client uses the stateless HTTP protocol to make requests to the ASP. NET application responds to user requests, sends the requested HTML code to the client, and the server does not maintain any client state. Consider a server with tens of thousands of concurrent users, which can consume a lot of resources if they maintain state for each user.

Because the stateless HTTP protocol is used as the communication protocol for the Web application, when the client requests the page each time, the ASP. NET Server will regenerate a new instance of the Web page. This means that some state of the client user in the browser or some modifications will be lost.

Remember when using ASP, in order to save the value of each text box, the data submitted before the use of a large number of session variables to save each text box value, and after the page is regenerated, the value of these session variables in the one by one assigned to each text box, this is a very time-consuming and laborious work.

While ASP. NET provides state management technology view state technology automatically saves and assigns the state of each control, and also provides a control state technique.

View state (ViewState): Uses one or more hidden fields to hold the control's data.

Of course we can also use it to save its own state data, by using ViewState, the built-in object, Viewstate[key]=value. This object is a dictionary type. A type conversion is required when the value is to be taken, int i= (int) viewstate[key]; Because the value in ViewState is the type of object. The data stored in the ViewState can be a simple data type or a custom type, but the custom type must support serialization (that is, when declaring a class, write the [Serializable] level on the Class). However, it is clear that using ViewState to save data is limited to the current user page, and it is not possible to pass information across pages. Because it can save the state of most controls by default, it consumes a lot of network bandwidth when it passes back and forth between the server and the client, and because it is stored on the client, it consumes too much memory from the client and affects execution efficiency. So for some controls that don't need to save state in ViewState, we can disable their view state through their EnableViewState properties. You can also disable all view state for this page by <%@ page enableviewstate= "false" >. View state is saved in a hidden domain HiddenField by the ASP. <input type= "hidden" name= "_viewstate" id= "_viewstate" value= "These states are keyed/ The value pair is saved as a collection and encoded in the BASE64 encoded format ">. Because BASE64 encoded strings can be decoded by many tools (such as Viewstatedecoder), it is dangerous to keep sensitive data in view state. If you do not want to store sensitive information in the view state, you can use the <%@ Page

Viewstateencryptionmode= "Always" > or set the value of viewStateEncryptionMode in the Webconfig pages node. You can also page.registerrequiresviewstateencryption () in the post code, but only if viewStateEncryptionMode is not set to never in the @page and pages nodes. There will be one more hidden domain name word for __viewstateencrypted.

Control state (ControlState): Saves state data for the control when the custom control is developed.

In order for the control to work properly, it is sometimes necessary to store control state data. For example, if you write a custom control that has different tabs that display different information, for the control to work as expected, the control needs to know which tab is selected in the round-trip process. The ViewState property can be used for this purpose, but the developer may have closed the view state at the page level, effectively interrupting the control. To resolve this issue, the ASP. NET page framework exposes a new feature called control state in ASP. 2.0. The ControlState property allows control-specific property information to be persisted, not as close as the ViewState property. To use control state, the control must call the Registerrequirescontrolstate method during initialization, and then override the SaveControlState and LoadControlState methods.

By default, the ASP. NET page framework stores control state in a hidden element of the page, and view state is also stored in this hidden element. Even when view state is disabled, or when the Session management state is used, the control state in the page is transferred to the client and then returned to the server. On postback, ASP. NET deserializes the contents of the hidden element and loads the control state into each control that has registered the control state.

From a series of technical references on MSDN, ControlState should be used primarily on custom controls, "The ASP. NET page framework provides the ControlState property as a way to store custom control data during a server round-trip", the original sentence on MSDN, Asp. NET2.0 just provides a basis for controlstate, when ControlState is a custom state-preserving mechanism, which means that the mechanism for maintaining state requires you to do it yourself, rather than ViewState, which has its own default state-keeping mechanism. The use of controlstate in custom controls may be the intention of Microsoft, to avoid disabling viewstate at the page level, the custom control will function properly. Of course, what this means is that some controls run correctly depending on their state information, and in asp.net1.1, if ViewState is disabled, the control does not work correctly. But the introduction of ControlState is different, because controlstate is disabled.

So Microsoft reminded developers to "use control state only for small amounts of critical data that is critical to the control during postback, instead of using control state as an alternate option for view state." To be clear, controlstate and ViewState are completely two things, and although they can accomplish the same task, the new controlstate is neither used to replace viewstate nor to be used as a substitute for viewstate. Its mission is to make up for ViewState's inability to accomplish tasks, and to allow developers to develop more robust controls. For example, it is important to develop a state of a custom control that does not work properly if the custom control is missing, so controlstate should play. And ControlState is a custom state-preserving mechanism that also restricts the use of controlstate free, and you not only have to register with the page in the OnInit method and call the Registerrequirescontrolstate method, and to rewrite Saveadaptercontrolstate (), Loadadaptercontrolstate (object state) two ways to implement what to save and how to save it. As I understand it now, if you need to save 10 different states of the control, you have to save one by one and then load it up. From this point also see the original intention of Microsoft, it is not very obvious, if you do not need to controlstate that do not use it, otherwise how it let us developers to do?

RELATED Links: http://kendezhu.iteye.com/blog/810562 3 and 5

Http://www.cnblogs.com/think-jerry/archive/2007/05/24/758240.html and its next article

Supplement: Cookies Session Application

Session

The session is similar to ViewState, and can also hold any standard data type and any object of the type derived from object, using the same method. However, the session can be saved across pages, and the same user can still get the data saved by the previous page after jumping to another page without changing the browser. The session state differs from ViewState, which is stored on the server side. Asp. NET creates a unique SessionID (120-bit identifier) for each session, and the SessionID is sent to the client as a cookie or URL, so that the server can maintain each client's session based on the client's SessionID. (So regardless of whether the program uses session["key"]= value in the server-side set up a session, there will be sessionid to the client, but the establishment of a session, SessionID has a place to use, it can be used to maintain each client's session). However, when the client user closes the browser and uses a different browser, a prolonged inactivity causes the session timeout to cause the server-side session state to be lost. Session state By default is stored in the server's memory, this is certainly an efficient advantage, but it consumes a lot of server-side memory, we can save it to the database and other places, the following to learn to configure session state in Webconfig:

Add the sessionstate node under the system.web node of Webconfig to the following configuration:

<system.web>

<sessionstate

cookieless= "UseCookies" cookiename= "Asp.net_sessionid"

mode= "SQL Server" timeout= "20"

sqlconnectionstring= "Data source=.\sqlexpress;integrated Security=sspi"

Sqlcommandtimeout= ">"

</sessionState>

</system.web>

Cookieless sets whether SessionID is sent to the client with a cookie or a URL, or through a detection decision. CookieName set the name of the cookie that holds the SessionID. Mode to save the session state, by default, InProc is saved in the server memory, which is set to be stored in SQL database. sqlConnectionString set the connection string. Sqlcommandtimeout set the timeout value.

When you are finished setting up, at the Visual Studio 2008 command prompt, enter:

Aspnet_regsql.exe-s. \sqlexpress-e-ssadd-s followed by the database server name

Added after the server will be more than a database aspstate, to remove the database, at the prompt to enter:

Aspnet_regsql.exe-s. \sqlexpress-e-ssremove

However, the state table is in the tempdb database, so restarting SQL Server will cause the session information to be lost and input:

Aspnet_regsql.exe-s. \SQLEXPRESS-E-ssadd-sstype P

The status table will appear in the ASPState database, and the session information will persist.

If you want to save the state data in your own database, enter:

Aspnet_regsql.exe-s. \sqlexpress-e-ssadd-sstype c-d database name

Then modify the properties in the sessionstate node:

Allowcustomsqldatabase= "True" allows custom databases to be used

sqlconnectionstring= "Data source=.\sqlexpress;initial catalog=tempdb;integrated security=sspi" link string plus database

RELATED links:

Http://www.cnblogs.com/shoru/archive/2010/02/19/1669395.html

Http://www.cnblogs.com/flier/archive/2004/08/04/30226.html (i)

Http://www.cnblogs.com/flier/archive/2004/08/07/30902.html (b)

Application

The usage of application is the same as the session, and is also saved on the server side. But application is a global object that is not limited to a single page browser, which is shared by all users. And it has no concept of timeouts, unless the server is shut down or restarted. The most common examples are web counters:

protected voidPage_Load (Objectsender, EventArgs e) {            intI=0; if(application["PageCount"]!=NULL) {application.lock (); Lock to prevent simultaneous access by multiple users (concurrent access) I= (int) application["PageCount"]; I++; application["PageCount"] =i;   Application.UnLock (); Unlock after Operation}Else{application["PageCount"] =0; } Label1.Text=i.tostring (); }