Mixin’ up Ninject, Castle Dynamic Proxy and WCF – Part I

They don’t need introduction: Ninject and Castle dynamic proxies are a must on many projects, as they help you design flexible and loosely-coupled software. If you mix them up you can get some neat stuff! On this series of (probably) 4 (small) posts I’ll present some code that enables Ninject bindings to dynamic proxies and then I’ll apply it to WCF service proxies and stubs.

To get started let’s say we have the following superb interface and implementing class:

        public interface IService
        {
            void Do();
        }

        class ServiceImpl : IService
        {
            public ServiceImpl(/* Dependencies here */) { }
            public void Do(){ ... }
        }

Using Ninject, binding IService to ServiceImpl is straightforward:

         var kernel = new StandardKernel();
         kernel.Bind<IService>().To<ServiceImpl>();

Whenever IService is requested Ninject will create an instance use ServiceImpl resolving its dependencies on the way. Now let’s say we’d like to log invocation of methods on ServiceImpl (we could go for caching, parameter validation or anything else, but for simplicity I’ll stick to an awesome console logger). A possible approach is to use Castle and create a dynamic proxy with an interceptor that logs method calls. Castle has two major types of proxies: with and without target. On this case, we need a proxy with target, since we want the call to actually reach ServiceImpl (the proxy target). To use the proxy whenever an instance of IService is needed the previous Ninject binding has to be enhanced as follows:

 var proxyGenerator = new ProxyGenerator();
 kernel.Bind<IService>()
    .ToMethod(ctx => proxyGenerator.CreateInterfaceProxyWithTarget(
        ctx.Kernel.Get<ServiceImpl>(),
        new ConsoleLogInterceptor()));

The proxy creation needs to be delayed because we still want the instances of ServiceImpl to be created by Ninject, hence the use of ToMethod (note that the interceptor could also be requested to the Ninject kernel). This code works but quickly becomes very verbose. What if one has multiple interceptors that should be resolved through the kernel? What if we want to bind another interface to a dynamic proxy in a similar way? When using Ninject and Castle at our current project, me and my colleague Antoine Aubry came up with some extensions to Ninject’s syntax that after some turns and tweaks allow you to rewrite the previous binding like this:

   kernel.Bind<IService>().ToDynamicProxy(p => p
         .WithTarget<ServiceImpl>()
         .UsingInterceptor<ConsoleLogInterceptor>());

On the next post I’ll cover some details on the implementation of those extensions.

Advertisements

One thought on “Mixin’ up Ninject, Castle Dynamic Proxy and WCF – Part I

  1. Pingback: Mixin’ up Ninject, Castle Dynamic Proxy and WCF – Part II | Luís Gonçalves

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s