And that is when problems might appear.  If you’re using Castle Windsor with the default ReleasePolicy (which is the LifecycledComponentsReleasePolicy) then each resolved transient instance will be stored in memory by that policy until the instance is explicitly released.  The benefit of this policy is that the container can automatically dispose any disposable transient dependency of a resolved component.  In my case, i’ve come to rely on that feature to achieve deterministic disposal behavior throughout my code base. 

Now, when you configure NServiceBus and pass it your instance of Castle Windsor, it obviously doesn’t change the ReleasePolicy like it does when it creates its own instance of Castle Windsor.   This is good because changing the policy of a passed in container would almost certainly have a huge behavioral implication for the application and such an action would be unacceptable when integrating a new framework into your project.   But since NServiceBus doesn’t have the notion of needing to release resolved components, every single transient instance it resolves through your container will be stored in memory until the application’s process is terminated.  Which means that you’ll leak instances of the following types for each message that your system needs to handle:

• NServiceBus.Grid.MessageHandlers.GridInterceptingMessageHandler
• NServiceBus.Sagas.Impl.SagaMessageHandler
• Your own MessageHandlers (and their transient dependencies as well)

If your MessageHandlers don’t have dependencies (highly unlikely if you’re already using an IOC container) then you’d still have 3 leaking instances per incoming message.  Add the number of transient dependencies of any handler to that and the number of leaking instances can increase dramatically.

First of all, if you do not depend on Windsor’s default ReleasePolicy’s behavior, then the easiest way to avoid this problem is definitely to set the container’s ReleasePolicy to the NoTrackingReleasePolicy like NServiceBus does itself when it’s configuring itself with a new instance of the container.

If you do depend on it, and you don’t want leaking instances that hang around forever, then the approach listed below is one way to solve this problem.  There are probably other solutions available, and while the approach listed below can definitely be considered to be a HACK, i do think it’s the best solution to this particular problem.

Because we don’t want to change anything about the way that we’re already using the container, we just need to make sure that NServiceBus’ usage of the container doesn’t conflict with ours.  That basically means that we need to make sure that the components that it resolves should not be tracked by the container.   There are 2 kinds of components that NServiceBus will resolve during normal operation:

1. Its own components that it needs to implement the features it offers you
2. Your message handlers that you need to handle incoming messages

The first category is easy to exclude from Windsor’s tracking behavior.  We can simply create our own ReleasePolicy which extends the default ReleasePolicy, and make sure that any instances of an NServiceBus-type are no longer tracked by the container:

Then you need to set this release policy somewhere in your application’s startup routine:

(in this case, IoC.Container returns an IWindsorContainer instance)

This will make sure that no instances of NServiceBus-types will ever leak in the container.  But now we still have to deal with our message handlers.  The solution to making sure they are not disposed is not the cleanest out there but hey, it works.  I basically introduced a base class that all my message handlers will need to inherit from, with the following implementation in the Handle method:

Uh oh… i just felt a great disturbance in the Force, as if tens of voices suddenly cried out in terror about my direct usage of the IoC container in a component!

Conceptually, this is wrong on many levels.  Then again, this makes sure that the message handlers (and their dependencies) that are resolved by NServiceBus will always be guaranteed to be released by the comtainer.  It might not be nice, but it avoids the memory leak and it doesn’t force me to change my other code.

And once NServiceBus is modified to release the components it resolves (if it’s ever modified that is…) i only need to get rid of my custom policy and the try/finally block.  Unfortunately, my existing message handlers will then all implement the Process method instead of the Handle method but that is quickly fixed with a simple rename-refactoring.

Even though this is a pretty big hack (IMHO), at least its impact on the code is minimal… it will be easy to get rid of once the real problem is solved in NSB, and there are no real downsides to this that i can think of at the moment.

The biggest issue i have with my previous implementation is that it required you to call it manually to protect potentially risky calls. I don't like having to call my circuit breaker whenever i want to make a service call because as a consumer of a service proxy, i shouldn't even know about the circuit breaker. I also don't want any coupling between my service proxy and the actual circuit breaker. Sounds like a good candidate for some AOP magic, right?

We're going to use Castle Windsor's Interceptors to make this work. First, the implementation of the CircuitBreaker class:

    public class CircuitBreaker : IInterceptor
    {
        private readonly object monitor = new object();
        private CircuitBreakerState state;
        private int failures;
        private int threshold;
        private TimeSpan timeout;
 
        public CircuitBreaker(int threshold, TimeSpan timeout)
        {
            this.threshold = threshold;
            this.timeout = timeout;
            MoveToClosedState();
        }
 
        public void Intercept(IInvocation invocation)
        {
            using (TimedLock.Lock(monitor))
            {
                state.ProtectedCodeIsAboutToBeCalled();
            }
 
            try
            {
                invocation.Proceed();
            }
            catch (Exception e)
            {
                using (TimedLock.Lock(monitor))
                {
                    failures++;
                    state.ActUponException(e);
                }
                throw;
            }
 
            using (TimedLock.Lock(monitor))
            {
                state.ProtectedCodeHasBeenCalled();
            }
        }
 
        private void MoveToClosedState()
        {
            state = new ClosedState(this);
        }
 
        private void MoveToOpenState()
        {
            state = new OpenState(this);
        }
 
        private void MoveToHalfOpenState()
        {
            state = new HalfOpenState(this);
        }
 
        private void ResetFailureCount()
        {
            failures = 0;
        }
 
        private bool ThresholdReached()
        {
            return failures >= threshold;
        }
 
        private abstract class CircuitBreakerState
        {
            protected readonly CircuitBreaker circuitBreaker;
 
            protected CircuitBreakerState(CircuitBreaker circuitBreaker)
            {
                this.circuitBreaker = circuitBreaker;
            }
 
            public virtual void ProtectedCodeIsAboutToBeCalled() { }
            public virtual void ProtectedCodeHasBeenCalled() { }
            public virtual void ActUponException(Exception e) { }
        }
 
        private class ClosedState : CircuitBreakerState
        {
            public ClosedState(CircuitBreaker circuitBreaker)
                : base(circuitBreaker)
            {
                circuitBreaker.ResetFailureCount();
            }
 
            public override void ActUponException(Exception e)
            {
                if (circuitBreaker.ThresholdReached()) circuitBreaker.MoveToOpenState();
            }
        }
 
        private class OpenState : CircuitBreakerState
        {
            private readonly Timer timer;
 
            public OpenState(CircuitBreaker circuitBreaker)
                : base(circuitBreaker)
            {
                timer = new Timer(circuitBreaker.timeout.TotalMilliseconds);
                timer.Elapsed += TimeoutHasBeenReached;
                timer.AutoReset = false;
                timer.Start();
            }
 
            private void TimeoutHasBeenReached(object sender, ElapsedEventArgs e)
            {
                circuitBreaker.MoveToHalfOpenState();
            }
 
            public override void ProtectedCodeIsAboutToBeCalled()
            {
                throw new OpenCircuitException();
            }
        }
 
        private class HalfOpenState : CircuitBreakerState
        {
            public HalfOpenState(CircuitBreaker circuitBreaker) : base(circuitBreaker) { }
 
            public override void ActUponException(Exception e)
            {
                circuitBreaker.MoveToOpenState();
            }
 
            public override void ProtectedCodeHasBeenCalled()
            {
                circuitBreaker.MoveToClosedState();
            }
        }
    }

Notice how the CircuitBreaker class implements Windsor's IInterceptor interface. The Intercept method will be called by Windsor whenever we try to call a method from a protected component. Within the Intercept method we can add the necessary logic to apply the Circuit Breaker pattern to the code that was originally called.

Now we just need to configure the Windsor IOC container to apply this bit of AOP magic for us.

First, we register the CircuitBreaker with the container:

            container.Register(Component.For<CircuitBreaker>().LifeStyle.Singleton
                                   .Named("serviceProxyCircuitBreaker")
                                   .DependsOn(new Hashtable { { "threshold", 5 }, { "timeout", TimeSpan.FromMinutes(5) } }));

Notice that we register the CircuitBreaker implementation with a Singleton lifestyle, a custom name and the required constructor parameters to create an instance of the CircuitBreaker.

Then we register our service proxy:

            container.Register(Component.For<IServiceProxy>().ImplementedBy<ServiceProxy>().LifeStyle.Transient
                                .Interceptors(InterceptorReference.ForKey("serviceProxyCircuitBreaker")).Anywhere);

Notice how we registered the service proxy as a transient component, while referencing the singleton CircuitBreaker interceptor. This means that each resolved instance of our service proxy will be protected by the same CircuitBreaker instance. If you have multiple services that you want to protect, simply register multiple CircuitBreakers with different keys and link each service you want to protect with the correct CircuitBreaker key.

If you're using an IOC container it's important to not use it all over the place. You basically use it in as few places as possible to resolve a component and you let the container sort out all of the dependencies. So in the few places where you use the container directly, you need to resolve the component, and in case of transient components you also need to release them through the container. Releasing it is very easy to forget, so i wanted something that would guarantee that the component would be properly released. Enter the Resolvable class:

    public class Resolvable<T> : Disposable
    {
        private readonly T instance;
 
        public Resolvable() : this(null) {}
 
        public Resolvable(object argumentsAsAnonymousType)
        {
            if (argumentsAsAnonymousType == null)
            {
                instance = IoC.Container.Resolve<T>();
            }
            else
            {
                instance = IoC.Container.Resolve<T>(argumentsAsAnonymousType);
            }
        }
 
        public T Instance
        {
            get { return instance; }
        }
 
        protected override void DisposeManagedResources()
        {
            IoC.Container.Release(instance);
        }
    }

The Resolvable class inherits from my Disposable class, so the Disposable pattern is correctly implemented.

From now on, instead of calling the container directly, i just instantiate a new Resolvable in a using block. Let's try it out.

I'm reusing my test component with a dependency from one of the previous posts:

    public interface IDependency : IDisposable
    {
        bool Disposed { get; set; }
    }
 
    public class MyDependency : IDependency
    {
        public bool Disposed { get; set; }
 
        public void Dispose()
        {
            Disposed = true;
        }
    }
 
    public interface IController : IDisposable
    {
        bool Disposed { get; set; }
        IDependency Dependency { get; }
    }
 
    public class Controller : IController
    {
        public IDependency Dependency { get; private set; }
 
        public Controller(IDependency myDependency)
        {
            Dependency = myDependency;
        }
 
        public void Dispose()
        {
            Dependency.Dispose();
            Disposed = true;
        }
 
        public bool Disposed { get; set; }
    }

Now, instead of resolving an IController directly through the container and having to dispose of it, i just do this:

        [Test]
        public void ResolvableInstanceIsProperlyReleasedAfterDisposal()
        {
            IoC.Container.Register(Component.For<IController>().ImplementedBy<Controller>().LifeStyle.Transient);
            IoC.Container.Register(Component.For<IDependency>().ImplementedBy<MyDependency>().LifeStyle.Transient);
 
            IController controller;
            IDependency dependency;
 
            using (var resolvable = new Resolvable<IController>())
            {
                controller = resolvable.Instance;
                dependency = controller.Dependency;
            }
 
            Assert.IsTrue(controller.Disposed);
            Assert.IsTrue(dependency.Disposed);
            Assert.IsFalse(IoC.Container.Kernel.ReleasePolicy.HasTrack(controller));
            Assert.IsFalse(IoC.Container.Kernel.ReleasePolicy.HasTrack(dependency));
        }

The container doesn't hold the reference to the instance, and both the instance and its dependency is properly disposed.

    public class Controller : IController
    {
        public IDependency Dependency { get; private set; }
 
        public Controller(IDependency myDependency)
        {
            Dependency = myDependency;
        }
 
        public void Dispose()
        {
            Dependency.Dispose();
        }
    }

This prompted the following comment by Bryan Watts:

So Controller is responsible for disposing of something it did not explicitly create? That’s a little presumptuous isn’t it?

> if you own a reference to an IDisposable instance, you are responsible for properly disposing of that instance.

I agree (and I’ve read your other article). However, in this case, Controller clearly does not own its dependency.

And Bryan is right. For a lot of languages, memory management rules can be summarized (somewhat simplified) like this:

• If you create an instance of a class, you are responsible for releasing/freeing/disposing it.
• If a factory creates an instance of a class, the factory is not responsible for releasing/freeing/disposing it. This burden falls upon the object which requested the object from the factory
• If you receive an instance of an object, you should not release/free/dispose it, unless you received the instance from a factory

So where does this leave us with the example code shown above? Clearly, we did not create the instance of the disposable dependency, so in theory, we are not allowed to dispose it. Then again, if we weren't using Dependency Injection we would have probably instantiated the disposable dependency in our constructor (or when we first need it). In that case, we would have been responsible for disposing the disposable dependency.

You could argue that the IoC container is in some way a factory which creates and supplies the dependency to our class. So according to the rules stated above, it would be allowed to dispose the dependency. The downside to this is that this means that our class (the Controller) has knowledge of the lifecycle of the dependency. We know that the dependency has been configured with a Transient lifecycle (which means the container creates a new instance whenever an instance of its class is needed) so we can safely dispose it. The problem is that this knowledge is implicit. It is nowhere visible in the code of the Controller class. The only place where this lifecycle is configured explicitly, is in the configuration of the IoC container so it would be wrong for the Controller to assume anything about the lifecycle of its dependencies.

After all, suppose someone makes a change to the code of the dependency which makes it possible to be used with a different lifecycle. Suppose someone makes the change to the dependency and then configures the IoC container to always return a singleton instance of this dependency. If nobody thinks about the fact that the Controller still assumes a Transient lifecycle of the dependency, the disposal of the dependency will not be removed from the Controller class. Once a Controller instance is created, and then disposed, it will try to dispose the instance of its dependency, which will cause problems because that instance is supposed to be used by other objects as well!

So what do we do? Do we dispose of the dependency in the Controller class because we know it's safe (until someone changes the dependency and/or its configuration with the container)? Or do we simply not dispose it (since we're not really allowed to do so without some kind of implicit knowledge of the 'outside world')?

Neither option sounds very appealing. The first option could lead to problems depending on possible future changes outside of the Controller class. The second option is already problematic because a disposable dependency is not being disposed of as fast as it should be. The disposal would basically be postponed until the instance is collected by the garbage collector.

Another alternative is to have the container inject a factory which can create transient instances of the dependency, instead of having the container inject the transient instance directly. This would fix all of the discussed problems: the controller would not need to dispose the injected dependency, and can safely dispose the instantiated disposable instances. However, having to create factories simply to avoid this problem seems a bit cumbersome. The implementation of the factory could lead to other discussions as well because of how the factory should create the actual instance and its dependencies, which is exactly the reason why we wanted to use an IoC container in the first place. True, the factory could resolve the instance directly through the IoC container, but then you're just moving the problem to a different class without actually fixing it properly.

This entire problem has been described as the Component Burden by Hammet, the original creator of the Windsor IoC container. Obviously, this is something that the container should solve for us instead of us having to worry about it. Ideally, the container would keep track of all of the disposable dependencies it has created to satisfy the creation of requested components. Then when the requested component would be released, the container could safely dispose of each transient disposable dependency it created to create the requested component. Luckily, the Castle developers have implemented this behavior recently, so if you're using a recent build of the Windsor IoC container, this problem should no longer occur and you shouldn't be forced to dispose of dependencies that were injected into your objects.

The reason why i'm not using it yet is because there were many attempts at implementing this, and most attempts had considerable downsides to them. This one has been committed to the trunk, so it's probably a good solution, but i'm not going to use this solution in production systems until it has had some more time to prove itself. So for now, i'm sticking with my approach where i manually dispose the injected dependencies. I know it's not the best approach, but until the real solution in the container is somewhat more proven to work without downsides, manually disposing the dependencies seems to be the lesser of multiple evils.

Keep in mind that i'm only talking about the Windsor IoC container. I have no experience with StructureMap, NInject or Unity, so i have no idea how these containers deal with this problems. If anyone with knowledge about these container could shed some light on how they deal with this, i'd be very interested in reading it

My mistake was that after i was done with the components that i asked Windsor to resolve, i simply disposed them (which in turn would dispose their dependencies) and i figured that would be enough, since my components are registered as Transient. That means that each time you request a Transient component, you get a new instance. This led me to believe that Windsor wouldn't need to hold a reference to the constructed components so i figured that simply disposing them would be enough, since they are IDisposables. Disposing them is a good thing obviously, but because the container was still holding references to the requested components, that's still a lot of memory that is being wasted because even though you've disposed them, they aren't eligible for Garbage Collection until they are no longer accessible. And because the container kept references to them, they remained accessible and were never collected. And there was my memory leak. Oops.

In order to prevent this problem in the future for myself and anyone else who reads this, let's go over a few examples which should make it clear how you should make sure that your components are properly released so they are eligible for garbage collection.

Let's start really simple. We have an IController interface and a simple Controller class which implements the IController interface:

In our tests, we'll use the following method to create and configure the container:

The IController interface is registered with the container, and the container will return a new Controller instance (because of the Transient lifestyle) whenever someone requests an IController instance.

The following test highlights the memory leak that i was experiencing:

When you request a component from the Container, it keeps a reference to that instance in its Kernel's ReleasePolicy object. If you merely dispose of your requested component, the ReleasePolicy still holds the reference to the component. This is what caused my memory leak.

So how do we avoid this problem? It's pretty easy actually:

Instead of just disposing our controller, we tell the container to release it. The container in turn knows that because IController inherits from IDisposable, it should dispose the Controller instance. It also removes the instance from its Kernel's ReleasePolicy object and once your own reference to the Controller instance goes out of scope, it's eligible to be collected by the Garbage Collector.

As you can see, it's very easy to make sure your components are properly released and eligible for garbage collection. But what about possible dependencies of your components? Let's take a look.

Suppose we define the following interface and implementation:

The dependency doesn't actually do anything, but bear with me

We modify the IController interface and Controller implementation like this:

And then we modify the configuration of the container like this:

Whenever we request an IController instance, the container will construct a Controller instance and will pass a MyDependency instance to the Controller's instance constructor. The question now is: does the container also track the instances of a requested component's dependencies? The answer is: no

We request an IController instance, which is tracked by the container. The IController's Dependency property contains an IDependency instance, which was also created by the container. But as the last line of the test shows: the container does not track instances of the requested IController's dependencies.

So what does that mean? If the dependencies don't require any cleanup, then this is great. We simply need to release the requested component, and the component and its dependencies will all be eligible for Garbage Collection.

(Note 27/01/10: the following part is no longer relevant as of Castle Windsor 2.1)

But what happens when the dependencies need to be disposed? Let's take another look.

We modify the IDependency interface and MyDependency class so it looks like this:

Now let's see what happens with the Controller's dependencies when we release the Controller:

The container holds no references, but the Controller's Dependency instance is not disposed! Notice however that the Controller has been disposed by the container. As i've mentioned earlier, if you own a reference to an IDisposable instance, you are responsible for properly disposing of that instance. So we modify the Controller's Dispose method so that it looks like this:

The previous test will now fail, because the Dependency will be properly disposed.

NOTE: i certainly don't recommend to implement your Dispose methods like i just did. This is just a simplified example. The proper way to implement the Disposable Pattern is discussed here.

Anyways, i hope it's clear now how you can make sure your IoC usage does not cause memory leaks, and that everything is properly disposed of.

I'm playing around with some supervising controller MVP stuff using regular ASP.NET webforms. Yes i know, i should be using ASP.NET MVC but i have a strict "i don't touch it before there's a final release"-policy when it comes to Microsoft products (as opposed to my "lemme just build the latest version of the trunk"-policy for various open source products). Anyways, what i'm trying to do is pretty simple. I have a view (ProductList.aspx) which uses a supervising controller (ProductListController). The view (the aspx page) will notify the controller when it needs to do something through events. The controller will then do whatever it needs to do and it will send the data back to the view through properties of the view. If that's not clear to you, read the post i linked to for a much better and detailed explanation.

Since ASP.NET automatically instantiates your aspx page, the easiest thing to do is to let the view create the controller and then pass itself as a parameter to the controller. But the controller also has other dependencies, such as a service which exposes the business logic that we need for this screen. So i have two options: i either create the controller myself and provide all the dependencies, or i use an inversion of control container to create the controller and to wire up all the dependencies. I don't want to have to modify my view code whenever i add/remove a dependency of the controller, so i go with the inversion of control container.

Suppose the constructor of the controller looks like this:

Here's where it gets tricky... since the view (which implements the IProductList interface) is asking the container to create a ProductListController, how can the container pass the correct IProductList dependency to the controller? We can't use the regular dependency look-up mechanisms because our controller actually needs the current view instance, but that view instance is asking the container to create the controller! By default, the container has no way whatsoever to resolve the IProductList dependency to the current view instance. So basically, what we want to do in this case is to manually provide the view dependency, but still have the container automatically provide the IProductsService dependency (hence the term 'automanual' which you have to admit is starting to sound pretty good at this point, right?). And of course, we want all of this to work automagically.

It turns out that Castle's Windsor actually does have some slick tricks to make this work. Here's how we can create the controller through the container from the view:

Told you it was slick! It's pretty easy actually... the parameter we pass to the Resolve method is an instance of an anonymous type with a view property. We set the view property to the current aspx instance (using the 'this' keyword obviously) and Windsor is smart enough to figure out that this value should be used to satisfy the view dependency instead of using it's normal look-up mechanisms. The result is that our controller has a reference to the current view, and its IProductsService reference is resolved as the container would typically resolve dependencies. Pretty sweet.

Btw, i googled the term 'automanual' and sure enough, it already exists... but it's not really used in the context of writing code so if this thing sticks, remember where you heard it first

Let's go back to the part of the code that performed the test:

The Time method has an Action parameter, which basically points to a block of code that will be executed when you call it. In this case the action() line causes the block of code to be executed. I have a habit of trying to write concise code, so the instantiation of the dummy instance is in both cases inlined in the block of code that will be executed by the Time() method. As Gael points out in his comment, Windsor generates a proxy when you request a component that has an interceptor assigned to it, and this is obviously a more expensive operation than simply new-ing a concrete instance. So this extra cost was reflected in the results as well.

If we change the test code to this:

Now, the difference is not so big as it was in the previous test: Time elapsed : 00:00:00.0100144 Time elapsed : 00:00:00.2403456

Again, this is for one million method calls... in a real world scenario, you probably won't notice the performance hit.

I wanted to see what the cost of this approach is, so i created the following interface and class:

Nothing special there... just a class with a method that doesn't do anything. Combine that with an interceptor that doesn't do anything:

And then we configure the component and the interceptor like this:

So what do we have now? We have a component which has a method that doesn't do anything. And we've assigned an interceptor that doesn't do anything... it just executes the original call without adding any behavior. Pretty useless, right? Right, but this is ideal to compare the runtime cost of merely intercepting calls to components. So the differences you'll see below are without adding the extra behavior to your components. The differences you'll see below are purely because each call is intercepted.

This is the code i used to test the difference:

First, we call the DoSomething method on a regular Dummy instance 1 million times. The time that takes is written to the Console. Then we call the DoSomething method (again, 1 million times) on an IDummy instance provided by the container, which has our interceptor attached to it (note: when you do not have an interceptor attached, there is NO runtime penalty!).

The output of the test (on my machine) is the following:

Time elapsed : 00:00:00.0100144 Time elapsed : 00:00:00.5808352

As you can see, the second time (using the intercepted instance) is significantly slower than using a concrete instance. But honestly, this is after calling the method one million times. And it only takes about half a second (on a virtualized Windows XP running on a cheap Macbook ) to call this method one million times. In a real-world scenario, you probably won't notice any performance hit unless the code that is intercepted is in a long, tight loop or something like that.

Having said that, i do think using the interceptor approach should be a temporary action in most cases. If you have to debug weird issues, i think adding an extensive logging/tracing interceptor to your components can be extremely valuable without having to pollute your code with logging/tracing statements. But if you want certain behavior to be added to your classes without it being configurable, there certainly are better options to use. PostSharp is a library which enables Aspect Oriented Programming without performance penalties. This approach basically allows you to add specific behavior to methods or classes by placing attributes on them. PostSharp will then modify the compiled byte-code to add the 'aspects' (the behavior that you want to add) to the real code. I'll write a post about this approach soon

If you're using the Windsor container, you could easily add logging behavior to the OrderRepository class without having to change any of the existing code. Windsor has this concept of Interceptors. Basically you can assign an interceptor to any component and you can plug in your custom behavior when the component is called. Lets get into an example... Since logging is such a common requirement, we decided to put it in one class instead of littering our entire code base with logging statements. So we wrote the following class:

This class implements the IInterceptor interface by implementing the Intercept method. When that method is called we simply construct the full method name, log when we enter the method, call the original method and then we log again when we leave the method. Nothing more, nothing less. Also notice how the LoggingInterceptor has a dependency on an ILogger instance. That instance will be injected by the container as well.

So first of all, we need to define the ILogger and LoggingInterceptor components:

Right... so now we need to add this behavior to the OrderRepository class. This only requires modifying the registration of the IOrderRepository component:

What we basically did was tell Windsor that whenever an IOrderRepository is requested, we should return an instance of OrderRepository and each time a method of that instance is called, it needs to be intercepted by our LoggingInterceptor.

So if we simply call the IOrderRepository methods like this (obviously these are dummy calls without real parameters and we're also ignoring return values):

The following output is logged:

21:53:42.6942016 Entering method: Components.OrderRepository.GetAll
21:53:42.6942016 Leaving mehod: Components.OrderRepository.GetAll
21:53:42.6942016 Entering method: Components.OrderRepository.FindOne
21:53:42.6942016 Leaving mehod: Components.OrderRepository.FindOne
21:53:42.6942016 Entering method: Components.OrderRepository.FindMany
21:53:42.6942016 Leaving mehod: Components.OrderRepository.FindMany
21:53:42.7042160 Entering method: Components.OrderRepository.GetById
21:53:42.7042160 Leaving mehod: Components.OrderRepository.GetById
21:53:42.7042160 Entering method: Components.OrderRepository.Store
21:53:42.7042160 Leaving mehod: Components.OrderRepository.Store

And we didn't have to change the OrderRepository implementation. In fact, we can use our LoggingInterceptor wherever we like, as long as the component to be logged is registered with Windsor. And we can easily switch between logging or no logging by switching config files.

Obviously, this was just a really simple example but i hope you realize how powerful this technique is and how far you can go with this.

By doing this, you actually create a strong dependency between your class, and the object that provides the configuration data. But you're not really dependent on the object providing the data, since you really only need a bit of data to function. So why not treat the data itself as a dependency?

Let's use our previous example. The OrderDataAccessor class will retrieve Orders from a database. In order to do that, it needs a connection string. Instead of letting the OrderDataAccessor class retrieve that connection string from a config file itself, we'll modify the constructor so that each instance retrieves the connection string when it is created:

If the container now needs to create an OrderDataAccessor instance, we get the following exception:

Castle.MicroKernel.Resolvers.DependencyResolverException : Could not resolve non-optional
dependency for 'Components.OrderDataAccessor' (Components.OrderDataAccessor).
Parameter 'connectionString' type 'System.String'

Which makes sense, since we haven't told the container about this 'dependency' yet. Since we're dealing with configuration data now, it's probably better to move our Windsor configuration to a config file as well. First we'll define the castle configuration section in our app.config:

Then we configure our components:

And that's it... Whenever the container instantiates an OrderDataAccessor instance, it will pass 'myConnectionString' to the connectionString parameter.

There's one issue with this though... In a real system, you'd have more than one DataAccessor class, and having to specify the connectionString for each one of them would be a prime example of suckage. So let's modify our config file a little bit:

That's better... Now we can just refer to the connectionString whenever we need it so we'd only have to modify it in one place.

Keep in mind that if you put the Windsor configuration in your app.config/web.config file, you need to instantiate the container like this:

So as you can see, you can also use the IoC container to keep dependencies on configuration-providing-classes completely out of your code by 'promoting' the required configuration data to actual dependencies of your components.

One thing you'll definitely need to know to properly use Windsor, is that of component instance lifetimes. After all, you want the container to manage your components and their dependencies. But there's more to the management of components than merely filling in dependencies. Should the container return a new instance of a component? Should it return an already existing instance? How do you control that behavior without having clients know about it? After all, should clients of components really know about that? Is that not an implementation detail that might be better of being properly encapsulated from clients?

Windsor allows you to register components with specific lifestyles. These are the lifestyles you can use:

• Singleton: components are instantiated once, and shared between all clients
• Transient: components are created on demand
• PerWebRequest: components are created once per Http Request
• Thread: components have a unique instance per thread
• Pooled: Optimization of transient components that keeps instance in a pool instead of always creating them
• Custom: allows you to specify a custom lifestyle... you'd have to specify a type that implements the ILifeStyleManager interface

The Singleton lifestyle is actually the default. I'm not so happy with that being the default, but oh well... If we continue with our previous sample, we can verify that Singleton is indeed the default lifestyle for a registered component. Suppose the component is registered like this:

Then the following test would pass:

But if we change the registration to this:

Then the test obviously fails because both requests to get an IOrderRepository instance will create a new OrderRepository instance.

You might be wondering what happens when you define a component as a singleton, but one of its dependencies is transient:

The answer is pretty straightforward: when you request an instance of type IOrderRepository the first time, it will create a new IOrderAccessor instance as well and pass it to the OrderRepository constructor. The second time you request an instance of type IOrderRepository, the container already has the singleton instance cached, so a new IOrderAccessor instance is not created.

If you really want this behavior (a new IOrderDataAccessor instance whenever the singleton IOrderRepository is requested) you can get it working pretty easily. Right now, our OrderRepository implementation uses Constructor Injection:

If we add Setter Injection as well the container will use the setter injector when we request the IOrderRepository instance after it has already been created:

Because we have both Constructor Injection and Setter Injection, the container will supply a new IOrderDataAccessor when the OrderRepository instance is created. And when it is requested again after its creation, the container will supply a new IOrderDataAccessor instance to the OrderRepository using the setter of the dependency.

It's nice to know that this is possible, but i wouldn't recommend this approach... It's very confusing and would certainly cause problems in multi-threaded scenarios. You're better off injecting an IOrderDataAccessorFactory object when the repository is created, and then let the repository request a new IOrderDataAccessor instance to be used locally whenever it's needed (as in: as a local variable during method execution, but certainly not as a field of the class).

There's also the other way around of course... suppose the dependency is configured as a singleton, and the component to be used is configured to have the Transient lifestyle. The singleton dependency will only be created once, and every time you request a transient component that is dependent on a singleton component, the container injects the singleton instance in the transient component.

By now, I hope you realize that an Inversion Of Control Container is about more than merely Dependency Injection and increasing testability. There's most certainly a lot more to it than that . I have a few more posts coming up about how using an IoC container can make your life as a developer easier.

How about some code to demonstrate? Suppose we have a class called OrderRepository which exposes methods such as GetById, GetAll, FindOne, FindMany and Store. Obviously, the OrderRepository has a dependency on a class that can actually communicate with some kind of physical datastore, either a database or an xml file or whatever. Either way, it needs another object to access the Order data. Suppose we have an OrderAccessor class which implements an IOrderAccessor interface. The interface declares all the methods we need to retrieve or store our Orders. So our OrderRepository would need to communicate with an object that implements the IOrderAccessor interface. Instead of letting the OrderRepository instantiate that object itself, it will receive it as a parameter in it's constructor:

This makes it easy to test the OrderRepository class, and it's also easy to make it use different implementations of IOrderDataAccessor later on, should we need to. Now obviously, you really don't want to do this when you need to instantiate the OrderRepository in your production code:

As a consumer of the OrderRepository, you shouldn't need to know what its dependencies are and you most certainly shouldn't need to pass the right dependencies into the constructor. Instead, you just want a valid instance of OrderRepository. You really don't care how it was constructed, which dependencies it has and how they're provided. You just need to be able to use it. That's all. This is where the IoC container comes in to help you. Suppose we wrap the IoC container in a Container class that has a few static methods to help you with instantiating instances of types. We could then do this:

That would leave you with a valid OrderRepository instance... one that has a usable IOrderDataAccessor but you don't even know about it, nor do you care how it got there. In other words, you can use the OrderRepository without knowing anything about its underlying implementation.

Let's take a look at the implementation of the Container class:

It just uses a static instance of Windor's Container and it registers the types we need... let's examine the following line:

this basically sets up the container to return a new instance of OrderDataAccessor whenever an instance of IOrderDataAcessor is requested.

We still have to make sure the Windsor container knows about the OrderRepository class by adding it as a known component like this:

By doing this, the Windsor container will inspect the type (in this case, OrderRepository) and it will see that its constructor requires an IOrderDataAccessor instance. We 'registered' the IOrderDataAccessor type with the container to return an instance of the OrderDataAccessor type. So basically, whenever someone asks the container to return an instance of an OrderRepository class, the container knows to instantiate an OrderDataAccessor instance to pass along as the required IOrderDataAccessor object to the OrderRepository constructor.

At this point, you may be wondering: "Why go through all this trouble to register the concrete implementation of IOrderDataAccessor to be used in code? We could just as well instantiate the type ourselves!". That's certainly true. The code would be slightly uglier, but you'd get the same behavior. Of course, the Windsor container supports XML configuration (either in the app.config or web.config or in a custom configuration file) as well as explicit configuration through code. So you can configure the container through code explicitly, but if there is a config file present, the container will use that configuration instead of the one provided through code. So you could define the defaults in code, and should you need to change it later on, you can just provide a config file.

You know what bothers me about our current implementation? We're still communicating with an OrderRepository instance. If we wanna be really flexible, it would be better if we were communicating with an object that implemented an IOrderRepository interface. So let's just define the following interface:

After all, that's all we care about as consumers of a IOrderRepository type. We shouldn't really care about the concrete implementation. We just need an interface to program to. So let's change the OrderRepository definition to this:

And then when we configure our IoC container we do it like this:

Now we can no longer ask the contianer for an OrderRepository interface. But we can ask for an instance that implements the IOrderRepository interface like this:

So now our client is completely decoupled from the implementation of IOrderRepository, as well as the dependencies it may or may not have.

Ok, lets suppose that this implementation makes it to the production environment. Everything's working but for some reason, someone makes a decision to retrieve the orders from a specially prepared XML file instead of the database. Unfortunately, your OrderDataAccessor class communicates with a SQL server database. Luckily, the OrderRepository implementation doesn't know which specific implementation of IOrderDataAccessor it's using. We just need to make sure that every time someone needs an IOrderRepository instance, it uses the new xml-based IOrderDataAccessor implementation instead of the one we originally intended.

Because we're using Dependency Injection and an IoC container, this only requires changing one line of code:

Actually, if we'd put the mapping between the IOrderDataAccessor type and the XmlOrderDataAccessor implementation in an xml file, we wouldn't even have to change any code! Well, except for the XmlOrderDataAccessor implementation obviously.

We can even take this one step further... After the change to the xml-based OrderDataAccessor went successfully, they (the 'business') all of a sudden want to log who retrieves or saves each order for auditing purposes.

Hmmm, alright then... We create an implementation of IOrderRepository which keeps extensive auditing logs so they can be retrieved later on. We could just inherit from the default OrderRepository implementation and add auditing logic before each method is executed. Then we'd only have to configure our IoC container to return a different instance of the IOrderRepository type whenever someone requests it:

Again, our client code does not need to be modified in any way, yet we did modify the runtime behavior of the application. Instead of retrieving the Orders from a SQL database, it's now retrieving them from an XML file, and the repository is performing auditing as well, without having to change any client code.

And if we were using the xml-configuration features of Windsor, we could get all of this working without even having to recompile the client-assemblies.

This was just an introduction to using an IoC contianer (Castle's Windsor specifically) and we briefly touched on benefits that you can achieve with this way of working. The Windsor container can do much more, but you'll either have to figure that stuff out yourself, or wait for future posts about its other features/possibilities