Improved State Management in ASP.NET

There are many methods to persist user data between requests. The methods available with ASP 3.0 were
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

 This document gives a brief description of each of these types.

Application

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

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.
 

Cookies

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

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.

QueryString

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.
 

New State Management techniques with ASP.NET
 

Cache

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.
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.

The Cache object has a lot more functionality than most of the other objects.
  

Context

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

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.
 

Web.config and Machine.config Files

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.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish