Will Beattie's Blog

  In my previous post I showed how you can very easily add Caching to your application by using Castle Windsor. The example used was a very basic implementation and whilst it can be useful for a large number of cases it didn’t cover the all important cache invalidation. In this post I hope to explain how with a bit of convention over configuration how you can invalidate your cache when an object changes. In the last post I was using the Method name combined with the arguments to build the cache key. Now to allow us to build a cache key that can be used when invalidating the cache the key needs to be related to the Result type. For this I’m going to create a simple interface called IAmCacheable to identify the object we want to cache. public interface IAmCacheable { object Key { get ; } } And make sure the object we want to cache implements this interface. public class Product : IAmCacheable { public object Key { get ; } ...

  This post assumes knowledge of Dependency Injection and AOP. AOP or Aspect-Oriented Programming is a very powerful way to add Cross-Cutting concerns to a system without impacting the core code base. Cross-Cutting concerns can cover non-functional requirements and also functional requirements. There are generally three approaches when implementing AOP. 1. Generate Dynamic Proxies at runtime to intercept method calls Spring .NET Castle Windsor 2. Post-Compilation Assembly Transformation Post Sharp 3. Attributes Just using Plain Old Attributes I really really don’t like annotating classes & members with Attributes so for me Dynamic Proxies is the only option and the performance hit is worth the productivity gains. The very common example of AOP is Logging. Logging is by all accounts a Cross-Cutting concern and so lends itself very well to the example. However I tend to think of Caching as a Cross-Cutting concern and really hate to see...