Keyvan Nayyeri

There is no doubt about the importance and effect of caching on the performance for any type of application. ASP.NET comes with a great set of caching capabilities that make caching one of the main and most important aspect of this technology. Usage and details of ASP.NET caching is covered very well and I'm not going to repeat it here.

The most common way to use ASP.NET caching is via HttpContext.Cache class that provides some static methods to work with the collection of cached objects in the memory.

There are many situations when you need to use caching in other types of applications (not ASP.NET web applications).

The drawback of HttpContext.Cache appears here where you're limited to HttpContext and without an ASP.NET context you're not able to use caching. This type of caching is strongly correlated with the state and you can't use it with your desktop Windows applications, console applications, WCF services or regular unit tests. Of course, there are some solutions to apply this caching with Windows Communication Foundation services or unit tests such as enabling the ASP.NET context simulation for your service configurations but these solutions need some extra effort (you can even simulate HttpContext with a local server for your desktop applications but why?!).

The better solution that I always have been using in my code to have stateless context is using an alternative class for caching. This class is HttpRuntime.Cache.

HttpRuntime.Cache is similar to HttpContext.Cache in the way that you use it and they're both located in System.Web assembly but HttpRuntime.Cache is the recommended solution for caching (later I'll describe that there shouldn't be any performance difference between them since HttpContext.Cache is just HttpRuntime.Cache).

I've been using this HttpRuntime.Cache class for a long time in my ASP.NET web applications but never used it in other types of applications until a recent effort to develop a WCF project that required caching both in a stateless component and in the WCF service. When I began to unit test my code, I found that this is really handy and helpful because enables caching for you independent from the ASP.NET caching and context. Sometimes as we read recommendations we use some stuff in our daily development without being aware of the philosophy behind them and this HttpRuntime.Cache thing was one of those. Rob Howard should be the god in this stuff and should have the best ideas about ASP.NET caching.

Note that there is no performance effect for using HttpContext.Cache or HttpRuntime.Cache because behind the scenes HttpContext.Cache is just HttpRuntime.Cache (reflector can prove this).

If you're interested to see HttpRuntime.Cache in action, let me show you a short introduction.

Suppose that I have defined a console application where I want to get a number from the user and store it into the cache then retrieve it from the cache again. The code should look like what you see here without requiring to create an ASP.NET context.

This can give me my desire output.

I can use this technique in other types of applications as well. For instance, in the below code I use it in a unit test.

For me the only confusing point (or question) about HttpRuntime.Cache is why it's located in System.Web while it could be something more general in default System types. The related question is why it's a member of HttpRuntime but is always accessible? I looked for the answer but couldn't find anything!