Skip to main content

Implementing Custom Castle Windsor Facilities

 

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>()
                    .ImplementedBy<WebCacheProvider>().LifeStyle.Singleton,
                Component.For<ICatalogQueryService>()
                    .ImplementedBy<CatalogQueryService>()
                    .LifeStyle.Transient
                    .Interceptors(new InterceptorReference(typeof (CacheInterceptor))).Anywhere);
        }

Or the XML version

<?xml version="1.0" encoding="utf-8" ?>
<castle>
  <components>
    <component id="CacheInterceptor"
             service="MyApp.Aop.CacheInterceptor, MyApp"
             type="MyApp.Aop.CacheInterceptor, MyApp"
             lifestyle="transient">
    </component>
    <component id="ICatalogQueryService"
             service="MyApp.Services.ICatalogQueryService, MyApp"
             type="MyApp.Services.Impl.CatalogQueryService, MyApp"
             lifestyle="transient">
      <interceptors>
        <interceptor>${CacheInterceptor}</interceptor>
      </interceptors>
    </component>
    <component id="ICacheProvider"
             service="MyApp.Core.Cache.ICacheProvider, MyApp"
             type="MyApp.Core.Cache.Impl.WebCacheProvider, MyApp"
             lifestyle="transient">
    </component>
  </components>
</castle>

What would be nice would be to be able to specify the Interceptor on all Components automagically and Castle allows for this with Facilities. Below is an implementation which achieves the desired result.

   public class CacheInterceptionFacility : AbstractFacility
   {
       protected override void Init()
       {
           Kernel.ComponentRegistered += Kernel_ComponentRegistered;
       }

       private void Kernel_ComponentRegistered(string key, IHandler handler)
       {
           if (typeof(IMustBeCached).IsAssignableFrom(handler.ComponentModel.Implementation))
           {
               handler.ComponentModel.Interceptors
                   .Add(new InterceptorReference(typeof(CacheInterceptor)));
           }
       }
   }

All you have to do is Inherit from the Castle.MicroKernel.Facilities.AbstractFacility and then override the Init.

You’ll see that we use the Interface IMustBeCached to identify the Component to apply the Interceptor too.

Now in your Bootstrapper all you have to do is call AddFacility on the WindsorContainer and you’re good to go.

        public void Configure()
        {
            container = new WindsorContainer();

            container.Register(
                Component.For<CacheInterceptor>(),
                Component.For<ICacheProvider>()
                    .ImplementedBy<WebCacheProvider>().LifeStyle.Singleton,
                Component.For<ICatalogQueryService>()
                    .ImplementedBy<CatalogQueryService>().LifeStyle.Transient);

            container.AddFacility("CacheInterceptionFacility", new CacheInterceptionFacility()); 

        }

Or the XML version

<?xml version="1.0" encoding="utf-8" ?>
<castle>
  <facilities>
    <facility
      id="CacheInterceptionFacility"
      type="MyApp.Aop.CacheInterceptionFacility, MyApp">
    </facility>
  </facilities>
  <components>
    <component id="CacheInterceptor"
             service="MyApp.Aop.CacheInterceptor, MyApp"
             type="MyApp.Aop.CacheInterceptor, MyApp"
             lifestyle="transient">
    </component>
    <component id="ICatalogQueryService"
             service="MyApp.Services.ICatalogQueryService, MyApp"
             type="MyApp.Services.Impl.CatalogQueryService, MyApp"
             lifestyle="transient">
    </component>
    <component id="ICacheProvider"
             service="MyApp.Core.Cache.ICacheProvider, MyApp"
             type="MyApp.Core.Cache.Impl.WebCacheProvider, MyApp"
             lifestyle="transient">
    </component>
  </components>
</castle>

 

Aside from reducing the configuration overhead another benefit of using this approach is that in your Debug or Test Environments you can easily deploy without any Interceptors and only enable them in your Staging and Production environments.

 

Popular posts from this blog

Freeing Disk Space on C:\ Windows Server 2008

  I just spent the last little while trying to clear space on our servers in order to install .NET 4.5 . Decided to post so my future self can find the information when I next have to do this. I performed all the usual tasks: Deleting any files/folders from C:\windows\temp and C:\Users\%UserName%\AppData\Local\Temp Delete all EventViewer logs Save to another Disk if you want to keep them Remove any unused programs, e.g. Firefox Remove anything in C:\inetpub\logs Remove any file/folders C:\Windows\System32\LogFiles Remove any file/folders from C:\Users\%UserName%\Downloads Remove any file/folders able to be removed from C:\Users\%UserName%\Desktop Remove any file/folders able to be removed from C:\Users\%UserName%\My Documents Stop Windows Update service and remove all files/folders from C:\Windows\SoftwareDistribution Deleting an Event Logs Run COMPCLN.exe Move the Virtual Memory file to another disk However this wasn’t enough & I found the most space was

3 Reasons Why Progressive Web Apps (PWAs) Won’t Replace Native Apps

Many people believe Progressive Web Apps (PWAs) are the future of the mobile web, but in my opinion, PWAs are not a replacement for native mobile apps. Here are three reasons why: 1. Native mobile apps provide a smoother & faster experience  Mobile websites, progressive or otherwise are slower and not as smooth. 90% of the time spent is spent using apps vs the browser . The single most significant contributing factor to a smooth experience on mobile is the speed of the network and latency of the data downloaded and uploaded. When you visit websites on desktop or mobile, there is a lot of third-party code/data that gets downloaded to your device, which more often than not has zero impact on the user experience. This includes: CSS (Cascading Style Sheets) JavaScript Ad network code Facebook tracking code Google tracking code The median number of requests a mobile website makes is a shocking  69 . On the other hand, native apps only get the data that is requi

Unit Testing Workflow Activities in .NET 4.0

  Recently during a catch up with my buddy Keith Patton I was (as I tend to do) singing the praises of the Workflow in .NET 4.0. The all important question about Unit Testing support was raised, I tried as best as I could to explain the new In and Out Arguments but I didn’t feel I was convincing enough, so I though I would clarify with a blog post. If you developed Workflows in .NET 3.5 then you will be well aware of the lack of Unit Test support which was due to many reasons but mostly in part to the complex Workflow hosting environment. When moving to .NET 4.0 Workflow Foundation from .NET 3.5 it pays to be conscious of that fact that there is no longer a distinction between Activities and Workflows. Everything derives from the System.Activities.Activity class. So the definition of a Workflow is just a collection of of 1 or more Activities. I have designed a very simple Rental Car Activity which takes the an Applicants age as the input and outputs a True or False depending o