Sometimes, when developing Web applications with ASP.NET, you encounter a problem like this. You have a small amount of data that rarely changes; you need that data again and again throughout the life of the application; and further, such data is shared among users accessing your application.

For example, you might have an online sales application that serves a limited region. Your application is aware of 50 different zip codes. For each zip code, you might associate the phone number of the sales office serving that zip code. This data might be used in various places in your application, including as a datasource for some Web server controls.

You could easily store this data in a database, such as Oracle or SQLServer. But you probably don't want to retrieve the data from the database every time you use it, even if you allow for caching on the server. I've found a better approach for such situations.

Initially, I store the data in a database. When the application starts up, I load the data into a single instance of a container, and then use that container whenever I need to access the data. This requires that you mind your Ps, your Qs, and your SIs (that is, static initializers). It also requires that you have a good understanding of how applications are started and stopped on the Microsoft IIS server, which runs the ASP.NET framework. In the rest of this article, I dive into these different topics to help you make sure your static data is well cared for.

Application Lifecycle

One big difference between an Internet application and a traditional client-side application is that, with an Internet app, each user doesn't get his own copy of the program running on the Web server. In addition, users have little control over the starting and stopping of the application. For you, as a developer of such applications, this can be a major pain in your exit ramp if you're trying to use code that relies on the application start-up, unless you know what you're doing. That's why a good understanding of the ASP.NET application lifecycle is necessary.

Note: The Web server does not run a separate copy of your application for each user accessing your web site. Bear this in mind as you read through the rest of this article, because you don't want to code global static variables as if each user has a separate copy of them. For per-user data, use session variables instead. For information on session variables, search the MSDN online help for HttpSessionState.

When you install your application on a Web server, it waits for somebody to access it. For example, suppose you're the Great Owner of the Microsoft.com Web site, and you install an application called superapp, which people access through the URL http://www.microsoft.com/superapp/default.aspx.

You went through the motions of configuring the application on the IIS server. But now it just sits there, waiting for the first user to come. When that finally happens, the IIS server goes through a bunch of rigmarole to initialize your application.

Now your application is running. And the user does his or her business (which is hopefully profiting you, or, in the very least, Bill Gates, since he needs the money). Then the user goes on her merry way. But what about the application? It's still running. Two minutes later, another user comes along to the same URL. Your application is still running, ready to serve up the Web pages.

When does it end? If the application goes idle for a certain period of time, the ASP.NET runtime will end your application for you. But if people are still connecting to the Web site, the application will still be running. Only after all is quiet will the thing finally shut down (assuming it doesn't crash, of course).

The whole process is somewhat complex (see the online help for the HttpApplication class for a list of the steps that take place; also check out Microsoft Knowledgebase article number 312607 for the whole details). But the important thing to worry about here is that when your application starts up, the ASP.NET framework creates an instance of HttpApplication for you. Or — and I'll give the details to this shortly — you can create your own class derived from HttpApplication, where you can store your global data (such as the zip code idea I mentioned earlier) inside the Global.asax file.

However, what I just said isn't the full story. You don't get just one HttpApplication. That's where it gets bizarre. The ASP.NET system actually creates multiple instances of HttpApplication (or of your derived class in Global.asax) in order to handle multiple requests. The whole idea is so that IIS and the ASP.NET system can handle high-performance Web sites that get heavy traffic.

Even though there are multiple HttpApplication instances, there's still no guarantee which of these are shared among which users. Each user accessing the site does not necessarily get his own instance of HttpApplication. In general, you don't want to make any assumptions about the individual instances of HttpApplication. And remember, even though there may be multiple HttpApplication instances, only one instance of the application itself is running on the server.

Your Data and the HttpApplication Class

Now, back to our nice little example about zip codes. Where should you store this data? If you've done traditional, non-Web programming, you probably created global classes to hold your data. In such classes, you typically only want one instance of your global data; so, you either make the data static (or shared in the VB language), or you use a singleton class, which is accessible through a static member function. When the application starts up, you initialize your global data, and go to town.

This same technique works in Web applications. You can create one set of your global data that gets loaded when the application starts. The only catch is that you need to recognize that you don't know when your application will start up and shut down, and you don't know how many users will be using it. But just to stir up the mud a bit, remember also that you don't know how many instances of HttpApplication you'll get.

One good (and Microsoft-approved) place to put your data is in your own application class you derive from HttpApplication. This class, as I mentioned earlier, is in your Global.asax file. However, just as in your traditional programs, youshould make the data static (or shared). Why is that? Remember that you might get multiple instances of HttpApplication (or some derived class thereof). Since you only want one set of your global data, if you make it static (or shared) you'll get only one set shared among these instances of HttpApplication, and ultimately among all users.

Following is an example, but first I need to make a quick comment, because I like to talk a lot and point out annoying little things. ASP.NET and ASP.NET 2.0 have two different ways that you derive a class HttpApplication. The old way involved creating a class that was somewhat cumbersome. The new way with 2.0 is much simpler; that's the approach I give in this example, which means this will work on the 2005 versions of the compilers. Here's a Global.asax file:

<%@ Application Language="VB" %>

<script runat="server">

    Public Shared GlobalNumber As Int32
    Sub Application_Start(ByVal sender As Object, _
    ByVal e As EventArgs)
        GlobalNumber = 100
        Logger.WriteLine("Application_Start")
    End Sub
       
</script>

Although not obvious from the code, this code creates a class derived from HttpApplication called Global_asax. The namespace for this class is ASP. The code I'm showing you here is an event handler called Application_Start, which is called when the application starts up. In this code, I initialize a shared/static variable called GlobalNumber to the value 100. Thus, I have my own static global variable.

Incidentally, if you want to access the Global_asax class from elsewhere you would do the following, shown in bold:

Label1.Text = ASP.Global_asax.GlobalNumber.ToString()

This line would be in an aspx.vb file, and I'm assuming you have a Label control called Label1. The line assigns the value of the static global GlobalNumber to the label control (by calling ToString to appropriately convert the number to a string).

Just to see what's going on, I made use of a handy little class I wrote called Logger, which I make use of in the code; the code calls Logger.WriteLine and logs a message just so I know the application started up. Yes, there are various trace utilities and such available, but I find this one serves my purposes pretty well. You're free to use it all you want.

Beginners Guide To ASP.NET

What is ASP.Net?

ASP.Net is Microsoft’s latest Web development platform that provides you all the foundation and services necessary to develop Enterprise class Web applications. It is definitely the next-generation ASP, with a total shift in the way you do web development compared to ASP. Initially called as ASP+, Microsoft further renamed it to ASP.Net.

Why ASP.Net?

ASP.Net has introduced several enhancements and improvements over classical ASP which makes it a compelling platform to look at for all ASP professionals as well non-ASP software professionals.

• Server controls make it simpler to do html style declarative programming with relatively less code.
• You can leverage your current programming skills by using languages like C#, VB.Net for coding the pages which are languages used in all types of programming unlike VBScript, JavaScript which are just scripting languages.
• Event driven model just like Windows programming helps write Event handlers easily with one click. Server side event handlers unlike ASP where all event handlers are written on the client side make the code safer from script hackers.
• Object oriented model versus Procedural model of ASP that separates code from the HTML pages making the project extremely structured and clean; hence reducing maintenance headaches.
• The code is compiled dynamically versus interpreted as in classical ASP which improves performance of the application.
• ViewState which automatically remembers the state of the page on post back and reconstructs the page taking the onus off of the developer to write explicitly hidden fields.
• Improved session state functionality-ASP.NET now supports moving sessions not only out of process, but also out of machine.
• Straight forward no-touch just copy deployment without having to register any components; components can be updated without having to restart the web server.
• Improved caching capabilities that enhance application performance.

Automatic recovery of application from memory leaks and crashes.

Getting Started with ASP.Net

The first thing a novice starting to get acquainted with ASP.Net development needs to download the .Net framework SDK itself. The Microsoft .NET Framework 1.1 Software Development Kit (SDK) includes the .NET Framework 1.1, as well as everything you need to write, build, test, and deploy applications using the .NET Framework 1.1, including documentation, samples, and command-line tools and compilers. This also includes ASP.Net 1.1.