State Management

State management is the process by which you maintain state and page information over multiple requests for the same or different pages. As is true for any HTTP-based technology, Web Forms pages are stateless, which means that they do not automatically indicate whether the requests in a sequence are all from the same client or even whether a single browser instance is still actively viewing a page or site. Furthermore, pages are destroyed and recreated with each round trip to the server; therefore page information will not exist beyond the life cycle of a single page.
ASP.NET provides multiple ways to maintain state between server round trips. Choosing among the options for state management available in ASP.NET will depend heavily upon your application, and it should be based on the following criteria:

• How much information do you need to store?

• Does the client accept persistent or in-memory cookies?

• Do you want to store the information on the client or server?

• Is the information sensitive?

• What sorts of performance criteria do you have for your application?

• ASP.NET supports various client-side and server-side options for state management.

Client-side options are:

• The ViewState property

• Hidden fields

• Cookies

• Query strings

Server-side options are:

• Application state

• Session state

• Database Client-Side State Management Options

Storing page information using client-side options doesn’t use server resources. These options tend to have minimal security but fast server performance because the demand on server resources is modest. However, because you must send information to the client for it to be stored, there is a practical limit on how much information you can store this way.

View State

Web Forms pages provide the ViewState property as a built-in structure for automatically retaining values between multiple requests for the same page. View state is maintained as a hidden field in the page.

You can use view state to store your own page-specific values across round trips when the page posts back to itself. For example, if your application is maintaining user-specific information — that is, information used in the page but not necessarily part of any control — you can store it in view state.

The advantages of using view state are:

• No server resources required. The view state is contained in a structure within the page code.

• Simple implementation.

• Automatic retention of page and control state.

• Enhanced security features. The values in view state are hashed, compressed, and encoded for Unicode implementations, thus representing a higher state of security than hidden fields have.The disadvantages of using the view state are:

• Performance. Because the view state is stored in the page itself, storing large values can cause the page to slow down when users display it and when they post it.

• Security. The view state is stored in a hidden field on the page. Although view state stores data in a hashed format, it can be tampered with. The information in the hidden field can be seen if the page output source is viewed directly, creating a potential security issue

Hidden Fields

You can store page-specific information in a hidden field on your page as a way of maintaining the state of your page.

If you use hidden fields, it is best to store only small amounts of frequently changed data on the client. ASP.NET provides the HtmlInputHidden control, which offers hidden field functionality. For more information on HtmlInputHidden see ASP.NET server Controls by Function.

Note If you use hidden fields you must submit your pages to the server using the HTTP POST method rather than requesting the page via the page URL (the HTTP GET method).

The advantages of using hidden fields are:

• No server resources are required. The hidden field is stored and read from the page.

• Broad support. Almost all browsers and client devices support forms with hidden fields.

• Simple implementation. :

The disadvantages of using hidden fields are

• Security. The hidden field can be tampered with. The information in the hidden field can be seen if the page output source is viewed directly, creating a potential security issue.

• Limited storage structure. The hidden field does not support rich structures. Hidden fields offer a single value field in which to place information. To store multiple values, you must implement delimited strings and the code to parse those strings.

• Performance. Because hidden fields are stored in the page itself, storing large values can cause the page to slow down when users display it and when they post it.

Cookies

Cookies are useful for storing small amounts of frequently changed information on the client. The information is sent with the request to the server.

The advantages of using cookies are:

• No server resources are required. The cookie is stored on the client and read by the server after a post.

• Simplicity. The cookie is a lightweight, text-based structure with simple key-value pairs.

• Configurable expiration. The cookie can expire when the browser session ends, or it can exist indefinitely on the client computer, subject to the expiration rules on the client.

The disadvantages of using cookies are:

• Limited size. Most browsers place a 4096-byte limit on the size of a cookie, although the support for 8192-byte cookie size is becoming common in the new browser and client-device versions available today.

• User-configured refusal. Some users disable their browser or client device’s ability to receive cookies, thereby limiting this functionality.

• Security. Cookies are subject to tampering. Users can manipulate cookies on their computer, which can potentially represent a security compromise or cause the application dependent on the cookie to fail. For more information see Introduction to Web Application Security.

• Durability. The durability of the cookie on a client computer is subject to cookie expiration processes on the client and user intervention.

Note Cookies are often used for personalization, where content is customized for a known user. In most of these cases, identification is the issue rather than authentication, so it is enough to merely store the user name, account name, or a unique user ID (such as a GUID) in a cookie and use it to access the user personalization infrastructure of a site.
For details about creating and reading cookies, see HttpResponse.Cookies Property and HttpRequest.Cookies Property.

Query Strings

A query string is information appended to the end of a page’s URL. For more information, see Introduction to Web Forms State Management.

You can use a query string to submit data back to your page or to another page through the URL. Query strings provide a simple but limited way of maintaining some state information. For example, they are an easy way to pass information from one page to another, such as passing a product number to another page where it will be processed.
<b> Note : </b>  Query strings are a viable option only when a page is requested via its URL.

You cannot read a query string from a page that has been submitted to the server.

The advantages of using query strings are:

• No server resources required. The query string is contained in the HTTP request for a specific URL.

• Broad support. Almost all browsers and client devices support passing values in a query string.

• Simple implementation. ASP.NET provides full support for the query string method, including methods of reading query strings using the HttpRequest.Params property.

The disadvantages of using query strings are:

• Security. The information in the query string is directly visible to the user via the browser user interface. The query values are exposed to the Internet via the URL so in some cases security may be an issue.

• Limited capacity. Most browsers and client devices impose a 255-character limit on URL length.

Client-Side Method State Management Summary

The following table summarizes client-side state management options and when you should consider using them.
Method Use when View state You need to store small amounts of information for a page that will post back to itself. Use of the ViewState property provides functionality with basic security.

Hidden fields You need to store small amounts of information for a page that will post back to itself or another page, and security is not an issue.

Note You can use a hidden field only on pages that are submitted to the server.
Cookies

You need to store small amounts of information on the client and security is not an issue.
Query string You are transferring small amounts of information from one page to another and security is not an issue. Note You can use query strings only if you are requesting the same page, or another page via a link.

Server-Side State Management Options

Server-side options for storing page information tend to have higher security than client-side options, but they can use more Web server resources, which may lead to scalability issues when the size of the information store is large. ASP.NET provides several options to implement server-side state management.

Management.
Session State

ASP.NET provides a session state, available as the HttpSessionState class, as a method of storing session-specific information that is visible within the session only. For more information, see Introduction to Web Forms State Management and Session State.
You can store your session-specific values and objects in session state, which is then managed by the server and available to the browser or client device. The ideal data to store in session-state variables is short-lived, sensitive data that is specific to an individual session.

Note If you store a dataset in application state, you have to cast it from Object back to a dataset

The advantages of using session state are:

• Ease of implementation. The session state facility is easy to use, familiar to ASP developers, and consistent with other .NET Framework classes.

• Session-specific events. Session management events can be raised and used by your application.

• Durability. Data placed in session-state variables can survive Internet Information Services (IIS) restarts and worker-process restarts without losing session data because the data is stored in another process space.

• Platform scalability. Session state can be used in both multi-computer and multi-process configurations, therefore optimizing scalability scenarios.

• Session state works with browsers that do not support HTTP cookies, although session state is most commonly used with cookies to provide user identification facilities to a Web application. For more information on using session state without cookies, see ASP.NET Configuration Sections.

The disadvantage of using session state is:

• Performance. Session state variables stay in memory until they are either removed or replaced, and therefore can degrade server performance. Session state variables containing blocks of information like large datasets can adversely affect Web server performance as server load increases.

Database Support
In some cases, you may wish to use database support to maintain state on your Web site. Typically, database support is used in conjunction with cookies or session state. For example, it is quite common for an e-commerce Web site to maintain state information using a relational database for the following reasons:

• Security

• Personalization

• Consistency

• Data miningThe following are typical features of a cookie-supported database Web site:

• Security. The visitor types an account name and password into a site logon page. The site infrastructure queries the database with the logon values to determine if the user has rights to utilize your site. If the database validates the user information, the Web site will distribute a valid cookie containing a unique ID for that user on that client computer. The site grants access to the user.

• Personalization. With security information in place, your site is able to distinguish each user on your site by reading the cookie on the client computer. Typically, sites have information in the database that describes the preferences of a user (identified by a unique ID). This relationship is known as personalization. The site can research the user’s preferences using the unique ID contained in the cookie, and then place content and information in front of the user that pertains to the user’s specific wishes and reacts to the user’s preferences over time.

• Consistency. If you have created a commerce Web site, you may wish to keep transactional records of purchases made for goods and services on your site. This information can be reliably saved in your database and referenced by the user’s unique ID. It can be used to determine if a purchase transaction has been completed, and also to determine the course of action should a purchase transaction fail. The information may also be used to inform the user of the status of an order placed using your site.

• Data mining. Information about your site usage, your visitors, or your product transactions can be reliably stored in your database. For example, your business development department may wish to use this data collected from your site to determine next year’s product line or distribution policy. Your marketing department may wish to examine demographic information about users on your site. Your engineering and support department may wish to look at transactions and note areas where your purchasing process could be improved. Most enterprise-level relational databases such as Microsoft SQL Server contain an expansive toolset for most data mining projects.

By designing the Web site to repeatedly query the database by using the unique ID during each general stage in the above scenario, the site maintains state. In this way, the user perceives that the site is remembering and reacting to him or her personally.

The advantages of using a database to maintain state are:

• Security. Access to databases is typically very secure, requiring rigorous authentication and authorization.

• Capacity. You can store as much information as you like in a database.

• Persistence. Database information can be stored as long as you like, and it is not subject to the availability of the Web server.

• Robustness and data integrity. Databases include various facilities for maintaining good data, including triggers and referential integrity, transactions, and so on. By keeping information about transactions in a database (rather than in session state, for example), you can recover from errors more readily.

• Accessibility. The data stored in your database is accessible to a wide variety of information-processing tools.

• Wide support. There is a large range of database tools available, and many custom configurations are available.

The disadvantages of using a database to maintain state are:

• Complexity. Using a database to support state management implies more complex hardware and software configurations.

• Performance. Poor construction of the relational data model can lead to scaling issues. Also, leveraging too many queries to the database can adversely affect server performance.

Server-Side Method State Management Summary

The following table summarizes server-side state management options and when you should consider using them.
Method Use whenApplication state You are storing infrequently changed, global information that is used by many users, and security is not an issue. Do not store large quantities of information in application state.
Session state You are storing short-lived information that is specific to an individual session, and security is an issue. Do not store large quantities of information in session state. Be aware that a session state object will be created and maintained for the lifetime of every session in your application. In applications hosting many users, this can occupy significant server resources and affect scalability.

Database support You are storing large amounts of information, managing transactions, or the information must survive application and session restarts. Data mining is a concern, and security is an issue.