State Management in Web Forms
This article discusses the ways in which the state management can be
handled in web forms. State management can be done either on client side or
server side as explained below.
Introduction to Web Forms State Management
Due to the nature of the standard transfer protocol ( http ), Web pages are
regenerated each time the page is posted to the server ,because of which all
information associated with the page, such as the values of controls contained
within the page, would be lost with each round trip from the browser to the
server and back.
To overcome this inherent limitation, automatic state management facilities
provided by the framework, which basically involve storing information either on
the client or on the server, are used.
State Management Recommendations
What is 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
Client-side options are:
- The View State property
- Hidden fields
- Query strings
Server-side options are:
- Application state
- Session state
Client-Based State Management Recommendations
The following sections describe options for state management that involve
storing information either in the page or on the client computer. For these
options, no information is maintained on the server between round trips.
1. View State
The Control.ViewState property provides a dictionary object 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 the 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.
The advantages of using view state are:
- No server resources required. The view state is contained in a structure
within the page code.
- Implementation is Simple.
- 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
- 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.
2. Hidden Form Fields
ASP.NET allows you to use HTML-standard hidden fields in a form. A hidden field
does not render visibly in the browser, but you can set its properties just as
you can with a standard control. When a page is submitted to the server, the
content of a hidden field is sent in the HTTP Form collection along with the
values of other controls. A hidden field acts as a repository for any
page-specific information that you would like to store directly in the page.
A hidden field stores a single variable in its value property and must be
explicitly added to the page. Then you insert your value into the hidden field.
ASP.NET provides the HtmlInputHidden control that offers hidden field
In order for hidden field values to be available during page processing, you
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 .
The advantages of using hidden fields are:
- No server resources are required. The hidden field is stored and read from
- Broad support. Almost all browsers and client devices support forms with
- 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
A cookie is a small amount of data stored either in a text file on the client's
file system or in-memory in 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
application. The cookies are saved on the client device, 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. A typical use
is to store a token (perhaps encrypted) indicating that the user has already
been authenticated in your application.
The browser can only send the data back to the server that originally created
the cookie. Therefore, cookies are a relatively secure way of maintaining
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
� 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.
- Durability. The durability of the cookie on a client computer is subject to
cookie expiration processes on the client and user intervention.
4. Query Strings
A query string is information appended to the end of a page's URL.
In the URL path above, the query string starts with the question mark (?) and
includes two attribute-value pairs, one called "category" and the other called
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 from one page to another page where
it will be processed. However, most browsers and client devices impose a
255-character limit on the length of the URL. In addition, the query values are
exposed to the Internet via the URL so in some cases security may be an issue.
In order for query string values to be available during page processing, you
must submit the page using an HTTP get method. That is, you cannot take
advantage of a query string if a page is processed in response to an HTTP post
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
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.
Server-Based State Management Recommendations
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.
ASP.NET offers you a variety of ways to maintain state information on the
server, as described in the following sections.
1. Application State
ASP.NET allows you to save values using application state (an instance of the
HttpApplicationState class) for each active Web application. Application state
is a global storage mechanism accessible from all pages in the Web application
and is thus 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.
The advantages of using application state are:
- Ease of implementation. Application state is easy to use, familiar to ASP
developers, and consistent with other .NET Framework classes.
- Global scope. Because application state is accessible to all pages in an
application, storing information in application state can mean keeping only a
single copy of the information ( for instance, as opposed to keeping copies of
information in session state or in individual pages ).
The disadvantages of using application state are:
- Global scope. The global nature of application state can also be a
disadvantage. Variables stored in application state are global only to the
particular process the application is running in, and each application process
can have different values. Therefore, you cannot rely on application state to
store unique values or update global counters in Web-garden and Web-farm
- Durability. Because global data stored in application state is volatile, it
will be lost if the Web server process containing it is destroyed, most likely
from a server crash, upgrade, or shutdown.
- Resource requirements. Application state requires server memory, which can
affect the performance of the server as well as the scalability of the
2. Session State
ASP.NET allows you to save values using session state, which is an instance of
the HttpSessionState class for each active Web application session.
Session state is similar to application state, except that it is scoped to
the current browser session. If different users are using your application, each
will have a different session state. In addition, if the same user leaves your
application and then returns later, that user will also have a different session
Session state is structured as a key-value dictionary structure for storing
session-specific information that needs to be maintained between server round
trips and between requests for pages. For more information, see Session State.
Session state enables you to:
- Uniquely identify browser or client-device requests and map them to an
individual session instance on the server.
- Store session-specific data on the server for use across multiple browser or
client-device requests within the same session.
- Raise appropriate session management events. In addition, you can write
application code leveraging these events.
- Once you add your application-specific information to session state, the
server manages this object. Depending on what options you specify, session
information can be stored in cookies, an out-of-process server, or a SQL Server.
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
- 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.
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.
3. Database Support
Maintaining state using database technology is a common practice 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 in conjunction with cookies. For example,
when a user first accesses your application, you might have the user 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 ( for example, a
customer number ). You can then use the cookie in subsequent requests to find
the user information in the database as needed.
The database support approach enables you to:
- Uniquely identify browser or client-device requests and map them to a unique
- Maintain state by relating stored information to the unique ID. You can use
the unique ID to query the database for information relating to that ID. You can
then modify the information and save it back to the database for use across
multiple requests for the same or different pages in your site.
- Raise appropriate events. A condition in the database may determine site
action. For example, if the user of a commerce site attempts to purchase
something that is not in stock, a database query may signal that the Web site
should prompt the user to make another selection.
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
- Data mining
The 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
- 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
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
- 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.
Jalajakshi Venkataramana is a software professional and works with Wipro Technologies in Bangalore, India.