John Sheehan : Blog

About This Post

Pluggable ASP.NET CacheManager

I wanted a single, common method for caching items for either the length of a request (in HttpContext.Current.Items) or longer (in HttpContext.Current.Cache). Here’s what I came up with.

There’s three common operations I use for caching: storing an item, removing an item and retrieving an item. I started by defining these methods in an interface:

public interface ICacheProvider
{
    void Store(string key, object data);
    void Destroy(string key);
    T Get<T>(string key);
}

Next up was my CacheManager class. I use this as a common interface to whatever ICacheProvider I want to use in each situation. Whenever you instantiate a CacheManager, you have to specify which provider you want to use, so I put that in the constructor. Then I implemented each of the common methods.

public class CacheManager
{
    protected ICacheProvider _repository;
    public CacheManager(ICacheProvider repository)
    {
        _repository = repository;
    }

    public void Store(string key, object data)
    {
        _repository.Store(key, data);
    }

    public void Destroy(string key)
    {
        _repository.Destroy(key);
    }

    public T Get<T>(string key)
    {
        return _repository.Get<T>(key);
    }
}

Right now, I only ever store cached items in two places: HttpContext.Current.Items for items that only need to live as long as a single request and HttpContext.Current.Cache for items that I need to live across requests (like a dynamically-generated CSS style sheet). So I wrote a ICacheProvider for each of these situations:

public class RequestProvider : ICacheProvider
{
    public void Store(string key, object data)
    {
        HttpContext.Current.Items.Add(key, data);
    }

    public void Destroy(string key)
    {
        HttpContext.Current.Items.Remove(key);
    }

    public T Get<T>(string key)
    {
        T item = default(T);
        if (HttpContext.Current.Items[key] != null)
        {
            item = (T)HttpContext.Current.Items[key];
        }
        return item;
    }
}

public class ShortTermProvider : ICacheProvider
{
    public void Store(string key, object data)
    {
        HttpContext.Current.Cache.Insert(key, data);
    }

    public void Destroy(string key)
    {
        HttpContext.Current.Cache.Remove(key);
    }

    public T Get<T>(string key)
    {
        T item = default(T);
        if (HttpContext.Current.Cache[key] != null)
        {
            item = (T)HttpContext.Current.Cache[key];
        }
        return item;
    }
}

For the ShortTermProvider you can specify additional options like absolute or sliding expirations using one of the other overloads on the Insert method.

Now I can easily and succinctly cache items in the desired location:

CacheManager cache = new CacheManager(new ShortTermProvider());
cache.Store("foo", "any-object-here");
string result = cache.Get<string>("foo");
cache.Destroy("foo");

Woot! In the future, if I ever need to implement memcached or Velocity, I can just write a new provider and plug it in.

kick it on DotNetKicks.com

  • I use a very similar approach for session variables as well.
  • Steve
    What's the point in using CacheManager instead of just using the ICacheProvider instances?
  • This is a nice implementation of a basic caching solution. You should also be aware of the Enterprise Library Caching Application Block. it offers extensibility to add new cache providers and is very easy to integrate with other Enterprise Library blocks, from my own personal usage I used it with the Membership provider for caching user tokens/privileges.

    http://msdn.microsoft.com/en-us/library/cc30910...

    The big difference in implementation of the Caching block is that the providers are created through a singleton factory which in my opinion makes alot of sense since cache stores generally are only ever 1 and only 1 per type of store so relying on a factory to handle the management of instances of the providers makes sense to me more than doing new __Provider(....) anytime you wish to access the cache.
  • Steve,

    I can offer some insight into the model that John was following when he created the cache manager. Following a pattern similar to this allows you to create loosely coupled code.

    With your question if you implemented the caching solution using only the specific classes if you ever decided you wanted to change your caching backing store from HttpRuntime.Cache (note: John, you should reference the cache as HttpRuntime.Cache instead of Httpcontext.Current.Cache, calling the context just causes extra processing to just resolve to HttpRuntime.Cache) to a sql data store or to a memory caching solution like memcache or velocity you will now have to go into you code and change every single usage of RequestProvider to use MemCacheProvider or whatever other implementation you wish to use.

    With a loosely coupled implementation that John created here, if you ever wish to switch from one provider to another you only ever need to change where it instantiates CacheManger to use the new provider instead. This brings me to my point about Enterprise Library's CacheManager having a factory method for creating the caching providers usage, this will allow you to only need to declare the CacheProviders once in your code and no matter how many times you change the concrete implmentation of ICacheProvider you will only ever need to change 1 line of code in the entirety of your project which is a great thing indeed.

    This idea of creating shared services that you can plug and play based off of interfaces is the basis of the idea of "Inversion of Control" or IoC that creates very robust and completely decoupled projects. Some of the most well known IoC frameworks are Microsoft's Unity, Spring.NET, Castle Windsor, Ninject, StructureMap to name a few there are quite a bit of frameworks out there for IoC. Creating loosely coupled code is definitely getting to the point where it is mandatory for a project to be a well made solution.
  • Great explanation Chris! Much better than I would have done.
  • Steve
    No you don't, what is the difference between

    ICacheProvider cache = new ShortTermProvider();

    or

    CacheManager cache = new CacheManager(new ShortTermProvider());
  • That is correct. However, if your CacheManager contains additional logic that is provider-independent (not demonstrated here), then you'd want to use the example code.
  • Steve
    If you want to add provider-independent code you can perfectly use something like an adapter, which implements ICacheProvider (which you could have done with CacheManager) and takes a ICacheProvider instance and then proxy the calls and do your extra logic.
  • Brian
    I've written something of the sort a while back..(not as good as yours), but I did something like this:

    public static Cache Cache {
    get {

    if (System.Web.HttpContext.Current != null && System.Web.HttpContext.Current.Cache != null)
    return System.Web.HttpContext.Current.Cache;

    return System.Web.HttpRuntime.Cache;

    }
    }

    That allows me to utilize the same concepts in Windows Forms and Windows Service applications....just some FYI
  • flalar
    Why do you call the method destroy??
  • CacheManager cache = new CacheManager(new ShortTermProvider()); // the constructor of CacheManager should be uses in looser way.

    You should take a look at some Dependency Injection framework (castle, spring.net, Nunit) and apply it instead of creating new CacheManager directly in code.
  • Betty
    Have you put any thought into this IoC approach when you require a CacheDependency? I basically took your approach and created a new Store method that took CacheDependency as a parameter.

    I'm a fan of the whole loosely coupled thing, however there are some times that I require (well, want more then require) a few different caching strategies for one project. Very data dependent of course. Any thoughts?
  • The problem with using parameter is that if you have a lot of calls in a class, you have to update them all if you want change providers.

    The example above is perfect for if you need different caching strategies in a project. Just create a provider for each strategy and use that provider when needed.
  • In other words....its the strategy pattern for caching? :)
  • I honestly didn't realize that this was the Strategy Pattern (I'm not well versed in patterns), but you are correct sir.
  • Paul
    Just a quick one on this...

    lock the cache when you're writing to it, for occasions where data is being refreshed by another process.

    lock (HttpContext.Current.Cache)
    {

    }
  • Can you elaborate on this a little more? I've never come across anyone
    discussing locks and caching (at least in regards to ASP.NET) before. I
    think it would be interesting to hear what the risk is of not using a lock.
  • smnbss
    I suggest you to implement a new method to implement the "read through" caching mechanism
    public delegate T GetObjectDelegate<T>();
    public V GetItemValue<V>(string objectID, V nullValue, GetObjectDelegate<V> getobject)
    {
    if (Cache[objectID] == null)
    {
    if (getobject == null)
    return default(V);

    V obj = getobject();
    if (obj != null)
    {
    Insert(objectID, obj);
    return obj;
    }
    else
    return nullValue;

    }
    return (V)Cache[objectID];
    }

    in this way you'll be able to verify if an object is in cache and load the object in cache if it's not just in a single line

    CacheManager.GetItemValue("key", null, delegate(){return getobjfromdb();})
  • Maarten Oosterhoff
    Great post, I've got something similar on my end.
    One thing though, and that is that in your implementations of the Get-method you access the storage twice. One time to check if there is anything in storage, and another time to actually get it. Since you don't lock anything, another thread can remove the item you are looking for. This will happen when you use the storage frequently.

    Something like the following will solve this.

    public T Get<T>(string key)
    {
    T item = (T)HttpContext.Current.Cache[key];
    if (item == null)
    item = default(T);
    return item;
    }
  • Thanks for the Explanation Maarten!
  • Only one thing I'd add to the code Maarten posted, I would recommend using the AS operator instead of a direct case, and make it a one line operation.

    return HttpRuntime.Cache[key] as T;

    This will automatically return default(T) if the cached item doesn't exist. Using Maarten's code if you try to get an object from the cache that can not correctly cast to the type T you will get can't convert exception for the object.
  • The method is Generic, not the class, so you can't use as with T (The type parameter 'T' cannot be used with the 'as' operator because it does not have a class type constraint nor a 'class' constraint). You could add a type constraint, but it would limit what types you could specify when calling the method.
  • I forgot about the as operator having a constraint of having to be a reference type, let me amend my post:

    var item = HttpRuntime.Cache[key];
    return item is T ? (T) item : default(T);

    Which is basically what the as operator does anyway.
  • Hi! Great Explanation John! ASP.NET is one of my favorite subjects. Its performance is good but only on a single server environment as we try to scale out; it will not work smoothly. But distributed caching solves this problem. Distributed caching is scalable and highly reliable. Even Microsoft also realized it and come up with its own solution of distributed caching. I think we should look into it.
blog comments powered by Disqus
© 2009 John Sheehan