Web Application State

A Web page is recreated every time it is posted back to the server. In traditional Web programming this means that all the information within the page and information in the controls is lost with each round trip. To overcome this limitation of traditional Web programming, the ASP.NET page framework includes various options to help us preserve changes. One  option involves keeping information on the client, directly in the page or in a cookie and another option involves storing information on the server between round trips. We will take a look at both the options.

Saving State in the Client

If we decide to save data in the client then that data is not stored on the server. This means that the page has to store all the data in controls so that it can be sent back to the server when the page is posted back to the server. The different ways in which you can save state in a client are discussed below:

HTML Hidden Form Fields

The default way of saving the state of the data is to use HTML hidden fields. A hidden field stores text data with the HTML <input style="hidden">. A hidden field will not be visibe in the browser but we can set its properties just like we set properties for other standard controls. When a page is posted to the server, the content of a hidden field is sent in the HTTP Form collection along with the values of other controls. In order for hidden field values to be available during page processing, we must submit the page using an HTTP post method. That is, you cannot take advantage of hidden fields if a page is processed in response to a link or HTTP GET method.

Cookies

A cookie is a small text file that stores data on the client's machine or is persistent in-memory during the client browser session. It contains page-specific information the server sends to the client along with page output. Cookies can be temporary with specific expiration times and dates or persistent. We can use cookies to store information about a particular client, session, or application. Cookies are saved on client machine, and when the browser requests a page, it sends the information in the cookie along with the request information. The server can read the cookie and extract its value. Cookies are a relatively secure way of maintaining user-specific data as the browser can only send the data back to the server that originally created the cookie.

Query Strings

A query string is information added to the end of a page's URL. For example, it looks like the following:

http://www.startvbdotnet.com/listbooks.aspx?category=asp&price=50

In the above URL , the query string starts with the question mark (?) and includes two attribute-value pairs, one called "category" and the other called "price." Query strings provide a simple and limited way of maintaining state information. Most browsers impose a 255-character limit on the length of the URL. Also, as the query values are exposed to the Internet via the URL, in some cases security may be an issue. In order for query string values to be available during page processing, we must submit the page using an HTTP get method. You cannot take advantage of a query string if a page is processed in response to an HTTP post method.

View State

The Control.ViewState property provides a way for retaining values between multiple requests for the same page. This is the method that the page uses to preserve page and control property values between round trips. When a page is processed, the current state of the page and controls is hashed into a string and saved in the page as a hidden field. When the page is posted back to the server, the page parses the view state string at page initialization and restores property information in the page.

Saving State on the Server

We can also save an application's state on the server. Saving an application's state on the server provides with more security than client-side options. The different ways in which you can save state in a server are discussed below:

Application State

An application's state is stored using the application's state object (HttpApplicationState class) for each active Web Application. Application state is a global storage mechanism accessible from all pages in the Web application and is useful for storing information that needs to be maintained between server round trips and between pages. Application state is a key-value dictionary structure created during each request to a specific URL. You can add your application-specific information to this structure to store it between page requests. Once you add your application-specific information to application state, the server manages it for you.

Session State

Besides application state, ASP.NET also can store session states using a session state object (HttpSessionState class) for each active Web Application. Session state is similar to application state, but it is scoped to the current browser session. If different users are using an application, each user will have a different session state. If a user leaves the application and returns later, that user will have a different session state. Session state is a key-value dictionary structure for storing session-specific information that needs to be maintained between server round trips and between requests for pages. Once we add our application-specific information to session state, the server manages this object for us. Depending on the options we specify, session information can be stored in cookies, an out-of-process server, or a SQL Server.

Using Database

Maintaining state using database is a very common method when storing user-specific information where the information store is large. Database storage is particularly useful for maintaining long-term state or state that must be preserved even if the server must be restarted. The database approach is often used along with cookies. For example, when a user access an application, he might need to enter a username/password to log in. You can look up the user in your database and then pass a cookie to the user. The cookie might contain only the ID of the user in your database. You can then use the cookie in the requests that follow to find the user information in the database as needed.