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

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