Will Beattie's Blog

  If you’ve been following my posts you would know that I love Castle Windsor . One of the many useful features I have found is the Facility and I’m going to try and give a good example how you can make use of this. In a recent post I showed how you can add Cross-Cutting concerns to your application by using Interceptors. Now when configuring the Container you can explicitly configure each Interceptor per Service but when you have lot’s of components it can get pretty hard to maintain after a while and can also introduce subtle issues if someone forgets to configure it correctly.   Below is how you would configure your Container without using a Facility. On the last line we are specifying the Interceptor explicitly. public void Configure() { container = new WindsorContainer (); container.Register( Component .For< CacheInterceptor >(), Component .For< ICacheProvider >() ...

  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 ; } ...