Question

I’m implementing a cache in a class library that i’m using in an asp.net application.

I created my cache object as a singleton pattern with a static method to update the cache which is really just loading a member variable/property with a collection of data i need cached (got some locking logic ofcourse). I figured it was a nice way to go since i can just access my data by calling

MyCacheObject.Instance.MyDataCollection 

I’m creating a new cache object to store a pretty big amount of data partitioned by some key. What i’m saying is i’m creating a new cache but this one will not load all of the data at once, but rather store a collection for each key accessed.

MyOtherCacheObject.Instance.MyOtherDataCollection(indexkey) 

This time the question about garbage collection was brought up. Since i’m storing a huge amount of data, wouldn’t it be a waste if it got gc’ed all of a sudden? Since it’s just a singleton pattern there is nothing ensuring data will stay in cache.

So my question is – what is best practice for implemeting a cache to handle this situation? I really don’t like a huge complex solution to this, and i know there is caching in System.Web but that seems a bit ‘off’ since this is just a class library, or what do you think?

Answer 1

In my opinion, the best solution would have the following characteristics:

• Uses the available caching services provided by the platform trying to avoid writing your own.

• Does not couple your class library to System.Web, in order to have the layers coherent.

• But if the class library is running inside an ASP.NET application the solution should not require to bring another caching implementation on (for example, the Enterprise Library Caching Application Block), which requires additional configuration and setup.

So, I would use an IoC strategy in order to allow the class library to use different caching implementations, based on the environment it is running on.

Suppose you define your abstract caching contract as:

public interface ICacheService  {     AddItem(...); } 

You could provide an implementation based on System.Web:

public AspNetBasedCacheService : ICacheService {     AddItem(...)     {         // Implementation that uses the HttpContext.Cache object     }  } 

And then have that implementation ‘published’ as singleton. Note that the difference with your original approach is that the singleton is just a reference to the ASP.NET cache service based implementation, instead of the full ‘cache object’.

public class CacheServiceProvider  {     public static ICacheService Instance {get; set;}  } 

You would have to initialize the caching implementation either by performing lazy initialization, or at application startup (in Global.asax.cs)

And every domain component would be able to use the published caching service without knowing that it is implemented based on System.Web.

// inside your class library: ICacheService cache = CacheServiceProvider.Instance; cache.AddItem(...); 

I agree that it is probably not the simplest solution, but I’m aiming for taking advantage of the ASP.NET cache implementation without sacrificing code decoupling and flexibility.

I hope I understood your question right.