ASP. NET Core-view status of State management, asp. netcore

ASP. NET Core-view status of State management, asp. netcore

In actual projects, you often need to save user information to simplify unnecessary repetitive actions and provide user-friendly and intelligent interaction methods. However, HTTP is stateless, and each new page request is received. ASP. NET provides different options for saving the status so that the status value can be saved on the client or server.

To save the status on the client, ASP. NET provides view status, cookie, and Parameter options. Due to security issues, there are some restrictions on using these statuses. On the server side, session objects, global application status, cache, and user configuration files can be used to save the status.

ASP. NET also provides some attributes for access status management. For example, the HttpSessionState object can be directly accessed in the Session attribute of the Page class. You can also use HttpContext to get the HttpSessionState. HttpContext. Current to return the active HttpContext object. The Session attribute of this class can also return the HttpSessionState.

These different status management options will be resolved respectively. The following example uses the ASP. NET Web Forms page and Textbox, Label, and Button controls to demonstrate different status functions.

View status

The view status is only available within the page. You can use the view status as long as you are on the same page. The view status creates a hidden HTML field on the page. This field is sent to the server because it is in the <form> flag. View status can be accessed using the ViewState attribute of Page. ViewState returns a StateBag object. You can use view status to read and write data by passing a key value to the indexer.

In the following sample code:

protected void Button1_Click(object sender, EventArgs e)    {        Label1.Text = string.Format("TextBox1.Text:{0}", TextBox1.Text);        Label2.Text = string.Format("ViewState[\"state1\"]{0}", ViewState["state1"]);        ViewState["state1"] = TextBox1.Text;    }

When the page is opened for the first time, the Bbutton1_Click method has not been called. Both labels display the initial values. Write one to the text box and click the button to call the Bbutton1_Click method for the first time. Then, the server will be sent a sending back request. In this case, the TextBox1.Text attribute returns the input data. Because the first Label is filled with this data, the second Label only displays the first part of the message, and ViewState ["state1"] returns NULL. Write two to the text box and click the button for the second time to send another sending back to the server. ViewState ["state1"] returns the previous data one and TextBox1.Text returns the new string two.

View status is stored using hidden fields on the page:

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUJNTAzMzI1MjcyDxYCHgZzdGF0ZTEFA3R3bxYCAgMPZBYEAgEPDxYCHgRUZXh0BRFUZXh0Qm94MS5UZXh0OnR3b2RkAgUPDxYCHwEFFlZpZXdTdGF0ZVsic3RhdGUxIl10d29kZGS/Lx64nbzEp3zavs9xOCFUE+yVx8Z01piL0emNSmVtSA==" />

The advantage of using hidden fields is that there is no timeout. As long as the page is open, hidden fields exist and are sent to the server at the next sending. If the user closes the page, the status disappears. If the user switches to another page, the status also disappears. The disadvantage of view status is that the status must be represented in a string. All view status data is always sent over the network, which may involve transmitting a large amount of data, reducing performance.

In particular, ASP. NET server-side controls use the view status. The server-side event model is based on this status model. When the form content is sent to the server, the form contains the previous value of the text box in the view status, include the current value in the text box. In this way, the event mechanism can determine whether it is a departure change event and call the Response Processing Method.