24 comments

• 

  Maarten Oosterhoff

  8 months ago

  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;
  }
  reply
• 

  John Sheehan

  8 months ago

  Thanks for the Explanation Maarten!
  reply
• 

  Marisic.Net

  8 months ago

  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.
  reply
• 

  John Sheehan

  8 months ago

  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.
  reply
• 

  Marisic.Net

  8 months ago

  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.
  reply
• 

  Marisic.Net

  9 months ago

  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.
  reply
• 

  John Sheehan

  9 months ago

  Great explanation Chris! Much better than I would have done.
  reply
• 

  Steve

  8 months ago

  No you don't, what is the difference between
  
  ICacheProvider cache = new ShortTermProvider();
  
  or
  
  CacheManager cache = new CacheManager(new ShortTermProvider());
  reply
• 

  John Sheehan

  8 months ago

  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.
  reply
• 

  Steve

  8 months ago

  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.
  reply
• 

  kevinpang

  9 months ago

  I use a very similar approach for session variables as well.
  reply
• 

  Steve

  9 months ago

  What's the point in using CacheManager instead of just using the ICacheProvider instances?
  reply
• 

  Marisic.Net

  9 months ago

  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.
  reply
• 

  Brian

  9 months ago

  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
  reply
• 

  flalar

  9 months ago

  Why do you call the method destroy??
  reply
• 

  duy lam

  9 months ago

  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.
  reply
• 

  Betty

  9 months ago

  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?
  reply
• 

  John Sheehan

  9 months ago

  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.
  reply
• 

  Bart Czernicki

  9 months ago

  In other words....its the strategy pattern for caching? :)
  reply
• 

  John Sheehan

  9 months ago

  I honestly didn't realize that this was the Strategy Pattern (I'm not well versed in patterns), but you are correct sir.
  reply
• 

  Paul

  9 months ago

  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)
  {
  
  }
  reply
• 

  John Sheehan

  9 months ago

  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.
  reply
• 

  smnbss

  9 months ago

  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();})
  reply
• 

  Edmartinez

  7 months ago

  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.
  reply