Alternative to HttpContext.Current.Cache

Question

What's an alternative to HttpContext.Current.Cache ?

I'm dealing with only the application tier and not the web tier so what is best for this?

We obviously don't want to use this because unit tests in the app tier will not have an HttpContext.

Would a simple list or dictionary object work?

Answer 1

A simple list or dictionary object could work, as long as you don't mind the cache items never expiring (unless you write code to remove them the list/dictionary)- probably not a good solution unless you are only caching a small quantity of data. One solution to look into for non ASP.NET apps is the Enterprise Library Caching Application Block .

Answer 2

I tend to work my hardest to not write any type of caching code. I leverage caching capabilities of other libraries such as StructureMap to handle both my dependency injection and caching needs. It provides a caching scope called Hybrid which will use ThreadLocal or HttpContext depending on where it's called from. It makes testing so much more effective.

Answer 3

You might want to consider creating a service pattern based cache interface for example ICacheService . You can then use Dependency Injection or some other factory pattern to wire up an implementation of what ever caching implementation you need.

For example, i have an application that uses various Cache implementations based on how i am using the application.

1). When in test mode, i use a " DummyCacheService " really does not cache at all since for my tests, i dont want data to cache.

2). Shared Hosting I use a AspCacheService which implements the standard HttpContext.Current.Cache

3). I then moved it to a dedicated server farm and used a MemCacheService implementation.

4). And recently am testing on Windows Azure so we recently created a AzureCacheService ...

The beautiful thing about this strategy is we did not have to change a single line of code in our application code... we simple wrote a new service derived from ICacheService and fully tested outside of the application and once it was ready, we used Windsor / Castle DI container to inject into our production site.

For reference, here is the interface that we use.... this could be modified to fit your need, but its worked great for us

public interface ICacheService
    {
        // TO-DO consider a cache group concept where you have groups of cache items, similar to cache manager in EntLib

        void Flush();
        void Add(string key, object item, int expirationInSeconds);
        void Add(string key, object item, int expirationInSeconds, CacheItemPriority priority);
        void Add(string key, object item, DateTime absoluteExpiration);
        void Add(string key, object item, DateTime absoluteExpiration, CacheItemPriority priority);
        void Add(string key, object item, TimeSpan slidingExpiration);
        void Add(string key, object item, TimeSpan slidingExpiration, CacheItemPriority priority);
        object Get(string key);
        object Remove(string key);
        T Get<T>(string key);
        IList<string> GetCacheKeys();
        bool ContainsData(string key);

    }