State Management in ASP.NET
Since all ASP.NET online applications are stateless by default, the state of controls is lost for each page submitted to the server. State management preserves the state of a control, web page, object/data, and user in the application.
From the control to the application level, all web programs nowadays require a high level of state management. But what exactly is state management and how is it useful? Let’s find out in this post.
Table of contents
- What is state management in ASP.NET?
- Type of state management in ASP.NET
- Level of state management
- Client-side state management
- Server-side state management
What is state management in ASP.NET?
ASP.NET online applications are stateless; state management is a way to keep state control and objects in an application. Whenever a page is posted to the server, a new instance of the Web page class is created. If a user enters data into a web application, that data is lost on the round journey from the browser to the server (MSDN). State management keeps and stores the information of any user until the conclusion of the user session reaches in a single line.
Type of state management in ASP.NET
In ASP.NET, there are two types of state management approaches, as shown in the diagram.
Level of state management
- Control level: By default, state management is provided by controls in ASP.NET.
- At the variable or object level, member variables at the page level in ASP.NET are stateless, thus we must explicitly maintain state.
- State management at the single or multiple page levels, i.e., the managing state between page requests.
- User level: The state of the application should be retained as long as the user is using it.
- At the application level, the state should be available for the entire application regardless of the user, i.e., it should be open to everyone.
- State management between or among two or more apps at the application to the application level.
Client-side state management
Following are the controls of client-side state management techniques in ASP.NET:
- Hidden Field: A hidden field is an ASP.NET control that can be used to keep modest bits of data on the client. It saves only one value for the variable and is the preferred method when the value of a variable is regularly updated. The client (browser) does not see the hidden field control since it is not rendered. A hidden field, like the value of a regular control, goes with every request.
- View State: View state is another client-side state management mechanism offered by ASP.NET for storing user data. For example, if a user needs to save data temporarily after a postback, view state is the ideal method. It saves data in a hidden field in the generated HTML rather than on the server.
View State manages page-level state, i.e., the state is available while the user is on the current page, but when the user navigates to the next page, the current page state is lost. Because View State is an object type, it can hold any form of data, although complicated data should be avoided owing to the necessity for serialization and deserialization on each postback. With the property EnableviewState set to true, view state is enabled by default for all ASP.NET server-side controls.
- Cookies: A cookie is a small text file that is created and kept on the client’s hard disc by the client’s browser. It does not make use of the server’s RAM. A cookie is typically used to identify users.
In simple words, a cookie is a tiny file that keeps the information about the user. When a user requests a page for the first time, the server produces a cookie and delivers it to the client along with the requested page, which the client browser receives and keeps either permanently or temporarily on the client system (persistent or non-persistence).
The browser checks for the presence of the cookie for that site in the folder whenever the user requests the same site. If the cookie is present, the request is sent with that cookie; otherwise, the request is processed as a new request.
- Control State: Another client-side state management mechanism is Control State. We can use the view state if we construct a custom control and wish to keep certain information. However, if the view state is deliberately disabled by the user, the control will not perform as planned. We must use the Control State attribute to get expected results for the control.
The control state is distinct from the view state. And here’s how you utilize the control state property -
Using the control state property is straightforward. First, override the control’s OnInit() method and add a call to the Page. With the instance of the control to register, call the RegisterRequiresControlState() function. Then, in order to store the appropriate state information, override LoadControlState and SaveControlState.
- Query Strings: The value in the URL is stored in the query string.
Server-side state management
- Session: Session management is a powerful strategy for preserving the state. In most cases, a session is used to store user data and/or to uniquely identify a user (or say browser). A session ID is used by the server to keep track of the current status of user information. When a user submits a request without specifying a session ID, ASP.NET generates one and transmits it with every request and response to the same user.
- Application: Application state is a strategy for managing server-side state. The date recorded in the application state is shared by all users of that ASP.NET application and may be retrieved from anywhere within it. Application-level state management is another name for it. The amount of data stored in the application should be minimal.
In this post, we saw how state management is a critical tool for maintaining the state of a control, web page, object/data, and user. It is essential to understand various state management strategies because all web apps of today require a high level of state management.
If you want to read more articles about ASP.NET, take a look at our website for more publications: https://www.partech.nl/en/publications
Originally published at https://www.partech.nl.