Static Application Variables

The Cache is the recommended location to store frequently used application data. However, using static application variables is another technique for efficiently storing frequently used data. An ASP.NET application consists of files and resources authored by you, and files and resources provided by ASP.NET. One of the characteristics of ASP.NET is that it truly is an application in the sense that there are application-level events and methods such as those defined in global.asax or in instances of HttpModule, and that we can also define application-level static variables.

A static variable, as related to object-oriented programming, is a variable shared by all instances of a class. For example, suppose you authored an ASP.NET page that defined a static variable:

static string backgroundColor = "blue";

All instances of that page would share the same string vs. creating their own copies of the string. The same concept can be applied to the entire application. For example, if we populate a DataSet to store all the URLs used in our site, we could perform this work within global.asax when the application starts:

<script runat="server">
public void Application_OnStart (Object sender, EventArgs e) {
 
    // Get the dataset from our custom business object
    DataSet siteUrls = SiteUrls.GetSiteURLs();
 
    // Store the dataset in the cache to never expire
    //
    Cache.Insert("SiteURLs", 
                  siteUrls, 
                  DateTime.MaxValue,
                  TimeSpan.Zero,
                  CacheItemPriority.NotRemovable,
                  null);
}
</script>

We could then request this DataSet from anywhere within our application:

DataSet siteUrls = (DataSet) Cache["SiteURLs"];

Easy enough, right? Yes, and no. Every time we fetch the item, we’re incurring a hashtable lookup and casting to the correct data type.

An alternative approach to handling this problem would be to define a static application variable, as shown in the following code. (This is only one alternative. You will get no noticeable performance gains or other improvements from using this technique instead of using the cache.)

<%@ Application Classname="MyApplication" %>
<script runat="server">
static DataSet siteUrls;
 
public void Application_OnStart (Object sender, EventArgs e) {
 
    // Get the dataset from our custom business object
    // and assign to the static application variable
 siteUrls = SiteUrls.GetSiteURLs();
 
}
 
</script>

Notice that we made a few changes to the global.asax file. We added a static variable siteUrls of type DataSet, set the Classname attribute of the Application directive, and removed all the code to insert into the cache.

To access the value of the siteUrls static variable defined in global.asax from anywhere within the application, we simply need to remember the name of our application, in this case MyApplication:

DataSet siteUrls = MyApplication.siteUrls;

Using static application variables allows us to skip the hashtable lookup and also does not require us to cast to the type. It’s definitely a handy technique!