There are many methods to persist user data between requests. The methods available with ASP 3.0 were This document gives a
brief description of each of these types.
Application object was
generally used when some data was to be stored which all users could use. The
size of the data was not really a constraint since there would be only a single
copy of that data. The data would be stored for the life of the application. In
ASP 3.0, the Application object was generally used to store pieces of data that
changed rarely such as contents of menu or Database connection strings (mainly
read only data).
In ASP.NET, such
configuration data as database connection strings are best stored in config
files. One thing to consider if you are using the Application object is that any
writes to it should be done either in its Application_OnStart event (in
global.asax). Since the config files are XML files, they can be changed whenever
required.
Session data is valid
only for a particular user session. The size of data is again not a constraint,
but it is to be kept to a minimum to make the application more scalable.
The major disadvantages
with Session was that it uses cookies and in ASP 3.0, it tied the user to one
particular Web Server since session data could not shared in Web farms or a
clustered environment. With ASP.NET, storing sessions on an external state
server or a database for managing session data.
Even then, Session object
is inefficient way to store data since the data is still stored in memory even
after the user has stopped using the site. This can affect the scalability on
busy web sites. The Cache object allows more control on release of memory and is
more suited for large data values. However, For small amounts of data, the
Session object can be a perfectly valid place to store user-specific data that
needs to persist only for the duration of the user's current session.
Even when not in use,
sessions carry some overhead for an application. Performance can be enhanced if
session is turned off on pages, which dont use them. Also, setting session
state to read-only can also optimize pages that read but do not write data to
sessions.
The biggest advantage of
cookies is that the data can be persisted for a variable amount of time. The
data can be persisted with for the life of the browser window or if required,
for months or years. Cookies are generally very small since they are maintained
on the client and have to be transferred to the server whenever that data is
required. Hence the contents should be as less as possible. It is a powerful way
to maintain state even in clustered environment or a web farm, which is the
reason why most web sites on the net use them.
Cookies are small text
files kept on the client machine which can be easily deleted by the user plus
the contents are not encrypted, hence sensitive information should never be
stored in cookies.
Hidden Form fields sent with the posting of form to the
server is generally used to store user specific data. The size of the data is
not a constraint. This technique was used more often than not in ASP 3.0, but
now made redundant by the new techniques introduced in ASP.NET like Web Controls
and ViewState. These techniques are discussed further.
QueryStrings like hidden form fields are user specific
data. Its lifecycle can be as brief as a single request or it can be maintained
through out the application. The size of the data is a major constraint, it
cannot be more than 1K. Another major constraint is that, since the data is
passed with the URL , the data is visible to the user and hence no sensitive
information is stored in QueryStrings unless it is encrypted to remove
human-readability. Also, Server.UrlEncode should be used to encode characters
that are not valid in URLs. However, they still continue to be a very good
alternative to pass information between page requests. DataGrids, which is a
ASP.NET web control uses querystrings in its hyperlink columns.
For long-term data storage, Cookie, Session, or Cache are
more appropriate options than QueryStrings.
Cache data is specific to the single user, a subset of users, or even all users.
This data persists for multiple requests. It can persist for a long time, but
not across application restarts. Also, data can expire based on time or other
dependencies. It can hold both large and small amounts of data effectively.
The
Cache object has a lot more functionality than most of the other objects.
The
Context object holds data for a single user, for a single request, and it is
only persisted for the duration of the request. The Context container can hold
large amounts of data, but typically it is used to hold small pieces of data
because it is often implemented for every request through a handler in the
global.asax.
ViewState is again a user
specific technique and is valid for a particular ASPX page. It can hold any
amount of data but it should be kept to the minimum it adds to the size of end
HTML to the client browser.
Web Controls use
ViewState to automatically maintain state between requests to the same page. The
size of the ViewState can be seen by viewing the source of the page and checking
for the hidden form field __VIEWSTATE. By default, the ViewState is turned ON,
so it should be turned OFF for all web controls, that dont need their data to
be persisted across requests. ViewState can also be disabled for an entire page
by adding EnableViewState="false" to the @Page directive.
These files are basically
XML files. The data in these files is common for the entire application, which
is available for the entire life of the application. The size of the data is
usually limited. Configuration settings are best kept in these files.
Each ASP.NET application uses a Web.config
file to set many of its properties, and each server has a Machine.config file
located in its system folder that is used as a basis for all applications. These
settings are used as defaults unless overridden. Configuration information is
read whenever the application starts, and is then cached. Since it is cached,
the application can read this data very quickly, so you should not be concerned
that your application will have a bottleneck because it has to constantly refer
to a text file for some integral information. Any changes to the config files
are reflected only on application restart. Database connection information,
default image paths, and paths to XML data files are some of the more common
pieces of data that are stored in the Web.config file.
Application
Session
Cookies
QueryString
Hidden Form Fields
With ASP.NET, there are four more methods to enable the developers to maintain user state. They are as follows
Cache
ViewState
Context
Config Files
Application
Session
Cookies
Hidden Form Fields
QueryString
New State Management techniques with ASP.NET
Cache
It offers incredible flexibility, versatility, and performance, and is therefore
often a better choice than Application or Session for persisting data within an
ASP.NET application. It is simply a name-value collection, but by using a key
value that is specific to a user, you can make the cached values user-specific.
The data in the Cache can be given an expiration period that is absolute,
sliding, or based on changes to a file.
One of the more powerful
features of the Cache object is its ability to execute a callback when an item
in the cache expires.
Context
ViewState
Web.config and Machine.config Files
Improved State Management in ASP.NET
0 comments
Hide comments
