Twitter Feed Popout byInfofru

Adventures in .NET Software Craftsmanship!

Per Method Call Lifecycle Proxy

Don’t ask why! but I had to code this workaround to plug into some legacy code efficiently and I decided to make the most of the opportunity. 


I kept constantly hitting a road block when interacting with a third party assembly that talked to some legacy web services.  In a nutshell, everything worked fine as long as I only called one method per instance of the class, needless to say this was terribly annoying so I decided to do something about it and learn some of the basics of Castle.DynamicProxy to build myself a generic proxy object that lets you implement a per method call lifecycle for an object.  Now this is not intended to be a Castle.DynamicProxy tutorial, but I will try to introduce some of the basics that I learned while coding my solution.


What is Castle.DynamicProxy?

Is an OSS project that provides you with the functionality to build dynamic proxy instances to inject functionality that addresses common application concerns.  In other words,  you could build proxies to address security, logging, monitoring and many other repetitive tasks that needs to be coded into any system.  It is used by a ton of very successful open source projects such as AutoMapper, NHibernate and Moq to name a few.   It is extremely easy to use as most of its functionality is exposed by a single class the Castle.DynamicProxy.ProxyGenerator which is usually managed as a single instance (singleton) within your application. 


Enough! Lets talk code.  The following snippet shows a simple IService interface and its implementation.  The implementation merely writes some information into the console that should gives us a visual clue (a guid) to easily identity the instance of the object that is servicing the request.


public interface IService {    
    Guid Id { get; }
    void DoSomething();
public class ServiceImpl : IService {

    public ServiceImpl() {
        this.Id = Guid.NewGuid();

    public Guid Id { get; private set; }

    public void DoSomething() {
        Console.WriteLine("INSTANCE GUID: " + this.Id.ToString());


When we use the functionality of the class, as illustrated in the following snippet, we see the same guid displayed every time the DoSomething method is called.  Now, if you recalled my objective is to implement a way to create a new instance of the object per method call. In other words, I want to see a different guid for a every single method call to an instance of a proxied IService implementation.


var service = new ServiceImpl();

// Should Output.
// INSTANCE GUID: ef45bb48-2f9e-4c9f-9c44-345f3a1700c0


The obvious solution is to build a proxy that would allow you to create a new instance to service the request every time a method is called.   We could code a very simple proxy specific for the IService interface that will do the job in not many lines of code, but there is no fun in that.  Plus, it would restrict the solution to be specific to the IService and its implementations.   By using Castle.DynamicProxy we can implement a generic solution that would allow us to inject this functionality into any object regardless of its contract by using a Proxy and an Interceptor.  The following is such interceptor.


public class SingleInstancePerCallInterceptor<T> : IInterceptor {
    private Func<T> builder;

    public SingleInstancePerCallInterceptor(Func<T> builder) {
        this.builder = builder;

    #region Implementation of IInterceptor

    public void Intercept(IInvocation invocation) {
        var changeTarget = invocation as IChangeProxyTarget;



Now, if you follow the code above the interceptor has a single constructor parameter that is a Func<T> used to build an instance of the class you are going to proxy.   In its intercept method, which as its name states just intercepts the method calls, there is functionality to build an instance of the class and service the request through Castle’s invocation API.  You might want to add additional logic to make the implementation more robust such as validating that the call is for a method not a property but for demo purposes I kept it simple.  Now the following code is a sample usage that produces the desired outcome by using this interceptor on the IService interface and its implementation object.


var generator = new Castle.DynamicProxy.ProxyGenerator();
var service = (IService)generator
        new ServiceImpl(),
    	new[] { new SingleInstancePerCallInterceptor<IService>(() => new ServiceImpl()) });

// Should Output.
// INSTANCE GUID: eb203315-d932-4f9f-8956-e9af3b2dcdde
// INSTANCE GUID: 19c528c0-3f35-4619-8276-dd5a270d8e72
// INSTANCE GUID: e7d9b66e-d846-4def-acfe-6a614cc75a78
// INSTANCE GUID: c7dc5dba-8440-478c-a692-5bc1cfe3d4c8
// INSTANCE GUID: 21a8cb42-8398-4bbf-9376-cb3c01ef8325


From the above snippet the only line that is somewhat confusing is the one where we are instantiating the service, but once you grasp what is doing is actually very simple.  As the method name implies you are creating a proxy object of type IService with a target, which in our scenario is never going to be used,  this allows the interceptor that is targeting the proxy to do the heavy lifting and switch the target of the invocation as needed.


Hopefully, this post illustrates some of the very basic yet powerful things that can be done with Castle.DynamicProxy and how it can help you get out of a bind using non-traditional coding techniques.