If you’re using NServiceBus together with your own instance of Castle Windsor, there is one thing you really need to look out for.  NServiceBus was originally developed with Spring.NET as its IoC container, but it’s been changed to support multiple containers in a similar manner as Agatha does it.  Agatha however, was originally developed with Castle Windsor as its IoC container, and as such is well aware of Windsor’s need to explicitly release resolved components.   NServiceBus unfortunately was not aware of this need, and a workaround that they have introduced is to set Windsor’s ReleasePolicy to the NoTrackingReleasePolicy (which doesn’t hold any instances in memory, but doesn’t provide any cleanup either) if you configure NServiceBus to use its own instance of Castle Windsor.  However, if you’re integrating NServiceBus into a project that is already using Castle Windsor, then you probably want NServiceBus to use your instance of Castle Windsor.

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.

If you have a web application which communicates with a remote service, it’s important to protect that web application from any problems the remote service might be dealing with. For instance, if the remote service goes down (for whatever reason) you really don’t want your application to keep making calls to this service. These failing calls increase the load on the service, which is already having problems, and will also block your threads which takes away resources from your application to deal with other requests. One pattern which is very suitable to reduce the problems for this situation is the Circuit Breaker (read that unless you’re familiar with the circuit breaker).

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:

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:

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:

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.

I wrote a post last week about a memory leak i had introduced in my code due to not properly releasing resolved components through the Windsor IoC container. I wanted to try to make sure that i’d never make that mistake again and this is the approach i came up with.

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:

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:

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

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

In my previous post i showed you how important it is to properly release the components you’ve resolved through the Windsor IoC container. At the end of that post, i showed an example where a disposable dependency of a component had to be disposed by the component. Basically something like this:

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

We ran into a huge memory leak this week. A bit of memory profiling with JetBrains’ dotTrace quickly showed that the Windsor IoC container was holding on to a lot of references. It turned out that i actually forgot to release the components i was requesting Windsor to construct for me. I use the container in my web-layer to compose every page’s Controller with its dependencies. And in my service layer, i use the container to compose every RequestHandler and its dependencies. So that’s two instances of the Container, in two separate AppDomains, and both are leaking a lot of memory due to my mistake.

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 apologize in advance for using the term ‘automanual’ but if you’ve been reading this blog for a while you already know i completely suck at coming up with good names. So bear with me, and you’ll probably understand what i mean as you work your way through this post. It really is pretty cool… i promise :p

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

Gael Fraiteur’s comment on my previous post made me realize that my performance test in the previous post wasn’t all that good…

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.

As i mentioned in a previous post, Windsor’s Interceptors are a great way to dynamically add behavior to a class. But what does it cost? There’s a lot of stuff going on behind to scenes to make that ‘magic’ work and surely, there’s a performance penalty involved somewhere.

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

The Windsor container makes it quite easy to add behavior to components, without having to modify their implementation. This could be useful in many scenario’s. Suppose you need to log whenever a method from our OrderRepository class is called. But we should be able to turn the logging on and off whenever we want. Preferably, without having to modify the code all the time. Now, you could easily write a logger class that checks for a configuration setting and only logs when needed. This approach would definitely work. But then there’s logging code all over the OrderRepository class and in most cases, it’s not even necessary since they only want to be able to log under certain circumstances. Should the OrderRepository class really care about the logging? Why litter the code with logging statements?

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.

Some classes need configuration data to function properly. This configuration data could be a database connection string, a path, a hostname, a network port, whatever. You typically deal with this by putting the configuration data in your app.config or web.config… either through a Settings file or in the AppSettings or maybe you’ve created your own configuration section or whatever. And in most cases, when a class needs this data, it simply retrieves it from the Configuration class or the class that was created through your Settings class.

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.