ASP.NET‘s Data Storage Objects
Introduction
In this brief tutorial, we‘ll look at five different ASP.NET objects we can use to store data. Two of these, the Application and Session objects, should be pretty familiar to anyone coming from ASP. The other three, Context, Cache and ViewState are brand new to ASP.NET. Each object is ideal under certain conditions, varying only in scope (that is the length of time data in them exists, and the visibility of the data), and it‘s a complete understanding of this variation that we are after. Also, most of these objects have alternatives that we‘ll briefly look at.
Scope
Since the only difference between all these objects is their scope, it‘s important to have a clear understanding of exactly what this means. Within the context of this discussion, scope refers to how data inside these objects (or the objects themselves) live for. For example, a user‘s user ID should exist until he or she logs out, but the new password he or she enters should only exist for the life of the individual request.
Scope also refers to the visibility of the data. There‘re only two types of visibility, data is either available throughout the entire application or for a specific user. An example of this would be the SMTP server name to use when sending an email which should be globally accessible, whereas an email address is specific to an individual user.
Commonality
The above objects all expose their data-storage capabilities via something similar to a HashTable.
In other words, getting or setting information into or out of any of them is very similar.
All can hold any object as a value, and while some can have an object as a key, some can only have a string - which is what you‘ll be using 98% of the time. For example:
//C# //setting Application.Add("smtpServer", "127.0.0.1"); Context.Items.Add("culture", new CultureInfo("en-CA")); Session.Add("userId", 3); //getting string smtpServer = (string)Application["smtpServer"]; CultureInfo c = (CultureInfo)Context.Items["culture"]; int userId = (int)Session["userId"];
HTTPApplication
The Application object is an instance of the System.Web.HTTPApplication class. Typically you would set values in the Application object on the Application_Start event of the Global.Asax or the BeginRequest event of a HttpModule. Logical values to store would be the SMTP server to use when sending out emails, the administrator‘s contact email address, and any other value which you might globally need across all users/requests.
Worker Process Recycling and Web Farms
While it‘s correct to say that data stored in the Application exists as long as the website is up, it would be incorrect to simply leave it at that. Technically, the data in the Application exists as long as the worker process (the actual aspnet.exe if you will) exists. This can have severe repercussion and isn‘t a mere technicality. There are a number of reasons why the ASP.NET worker process recycles itself, from touching the web.config, to being idle, or consuming too much RAM. If you use the Application object by setting values to it in the Application_Start event and only read from it in your classes/pages, then no problem. When the worker process recycles itself, Application_Start will fire and your values will be properly set. However, if you set a value in the Application_Start event, update the value later on, when the worker process recycles itself, it‘ll default back to the Application_Start value.
Something else to keep in mind is that data stored in the Application object is specific to a computer and can‘t be (easily) shared across web farms.
Alternatives
The Application object might have been quite useful in Classic ASP, but a number of better alternatives (in my opinion) are now available.
Web.Config
If you require values that are readonly/constants (such as our SMTP server example), consider using the web.config. Unlike values in the Application, the web.config can be easily and quickly changed. You can do considerably advanced things in the web.config, check out my tutorial on Creating Custom Configurations.
Constants
You can leverage the Object Oriented nature of ASP.NET and create a utility class with public constants. To be honest, unless you are just mocking something up, I‘m not sure why you would ever use this method over using the web.config. It really gives you nothing except for headaches in the long run.
HttpCache + (XML | DB)
While custom sections in the web.config is definitely the way to go for read-only values, what can we do about read/write values and avoid worker process recycling? The answer is to store values in an XML file or database. While you could do the same thing in classic ASP, you can now leverage a new storage object, the HttpCache (which we‘ll cover next) to avoid any major performance penalty you would otherwise have. This also avoids any web farm issues you‘d have with the HttpApplication class.
Conclusion
It is my opinion that the usefulness of the HttpApplication class, from a data storage point of view, is greatly diminished in ASP.NET. Powerful custom configuration sections in the web.config are a far more elegant and flexible solution for read-only values. Using XML files or a database is ideal for read/write values and web farms, and when combined with the HttpCache object leaves poor‘ol Application in the dust.