Maintaining state in ASP.NET: Know your
Tony Patton, TechRepublic
Developing robust solutions with ASP.NET requires a thorough understanding of the platform.
part of most Web applications is maintaining data or state between pages. Here's a
look at ASP.NET's four ways to maintain data.
The state of things
A quick review of state as it applies to a Web page helps with the concepts in this article. A good
description is the current state of a page which includes the current value of all variables and
controls on the page for the current user and session.
It is worth mentioning that the Web is inherently stateless since the HTTP protocol is stateless.
b server treats every HTTP page request as an independent request. By default,
everything on a page is lost when/if you go to another page.
Developers' skills are used to maintain the state of all or a portion of a Web page. In the past,
cookies or the que
ry string were often used to achieve this goal. A development platform like
ASP.NET provides other ways to maintain state.
Different approaches to state
ASP.NET provides four ways to maintain state within a Web application. The following list
provides an o
verview of each approach:
A data repository available to all classes in an ASP.NET application.
The data is stored in memory on the computer. It is available to all users and sessions for
This approach pro
vides the ability to save the state of a specific control on
a page; this is especially true for data controls like DataGrid and GridView, where
control state is used to store behavioural data. The control state is used to provide paging
and sorting functi
onality in the GridView control. It cannot be modified or directory
A data repository available on a user by user basis; that is, it stores data for
individual users. By default, session state is enabled.
stores the state of all controls on a page. It is applicable to
only that page, so every page maintains its own view state. It is enabled by default for all
While control state does not provide programmatic access, you can work with the othe
r states, as
I explain below.
ing application state within a site is as simple as using the Application keyword and
assigning or accessing one of its values. The Application object
as well as the ViewState and
Session objects use
d for view and session state
is a Dictionary object. With that said, entries
are assigned index values as well as data values. The following C# snippet assigns a value to the
Application state variable ApplicationName:
Application["ApplicationName"] = "
Application state variables live within the application, so they are accessible to all users.
Problems may arise when/if two users attempt to write data to the same Application entry. This
may be avoided by locking the object whe
n a data change is made. Also, Application state values
are cleared during server reboot and do not carry over to other processors or servers in a cluster
or farm environment.
A session begins when a user accesses a Web application. It ends w
hen they leave the
application or a certain amount of time has passed with no site activity. The Session state object
can be used to maintain values during a user's session.
The values in the Session object are only applicable to a certain user and may not
be accessed by
other users. Like the Application object, the Session object is Dictionary, with values accessed
according to their index values. The following VB.NET snippet stores a value in the Session
variable called UserName:
Session state may be enabled on a page by page basis with the EnableSessionState attribute of
the Page directive. Also, it may be configured for a site via the web.config file. There are a
variety of options available when using session state
, such as signaling whether cookies are used,
storing data in a database, and the length of the timeout.
By default, all pages have view state enabled. The actual data is stored in a hidden field on the
take a look at a page's source, an
d you'll quickly find the field hosting the data. The data
is not encrypted, so it does present security risks; however, it is Base64 encoded, which doesn't
make it easily read by the naked eye.
Like session state, view state may be disabled on the page le
vel via the EnableViewState
attribute of the page directive. Likewise, most individual controls have the same property
available. It may be disabled for the entire site in the web.config file.
Like the other state objects, the Dictionary approach is used,
as the following C# snippet
ViewState["CurrentCount"] = 2;
This entry is maintained for the life of the page; it is gone when the page is no longer loaded.
The size of the hidden field used to maintain view state can become large, so disable
it is not needed.
Choosing the right method
The interesting aspect of the many available ASP.NET features is when to use one over another.
The choice often depends on the development team's preferences, but there are some guidelines
for using o
ne of the options for maintaining state.
If you're worried about bandwidth or server resources, you should remember that session and
application states utilise server resources, and view state uses bandwidth to carry that hidden
field at all times. With se
curity, the biggest hole is view state; it is available by viewing the page
source. All of the states are accessible via your favourite language, but you should keep scope in
mind with each approach and choose the one that best fits the situation.
n't forget the older methods of cookies and the query string
they are still viable in