Configuring IUnityContainer

I’m using the IUnityContainer from the Composite Application Guidance in my current Silverlight project for Dependency Injection and this morning, I came across something that I couldn’t find documented anywhere. Initially, all my registered dependencies were being created using other dependencies that I had registered with the container. For example, I had the CustomerOrderService below and it was created using an IEventAggregator that was already registered in the container.

    public class CustomerOrderService : ICustomerOrderService
    {
        public CustomerOrderService(IEventAggregator evAg)
        {
            this.eventAggregator = evAg;
        }
    }

I was just registering my service with the container and letting it do all the work.

this.container.RegisterType();

However, this morning, I wanted to add a simple string to my constructor so that I could pass in the URI for a web service instead of hard coding it in the service class. After digging around a little in the docs and eventually just playing with the code until it worked, I came up with two ways of doing this.

First, I modified my service to have two constructor arguments:

    public class CustomerOrderService : ICustomerOrderService
    {
        public CustomerOrderService(IEventAggregator evAg, string uri)
        {
            this.eventAggregator = evAg;
            this.baseUri = uri;
        }
    }

Then, I came up with the two ways to register this service in code with the container. First, you can tell the container how to configure your dependency registration.

this.container.Configure().ConfigureInjectionFor(
    new InjectionConstructor(typeof(IEventAggregator), "URI GOES HERE"));

When the container is asked to create a CustomerOrderService object, it is configured to send in an IEventAggregator instance that it resolves internally and the URI string above. Of course, in a real world app, that URI would actually be a URI that I get from configuration.

Alternatively, you can tell the container what to do when you register the type:

this.container.RegisterType(
    new InjectionConstructor(typeof(IEventAggregator), "URI GOES HERE"));

This is a little cleaner because you’re going to have to register the type anyway and it makes sense to configure it at the same time.

By allowing the developer to specify an InjectionConstructor to use, the UnityContainer gives the developer a much more flexible way to register his dependencies.

0 comments on “Configuring IUnityContainer

  1. Added to the RSS feed.

  2. Added to the RSS feed.

  3. Niklaus Wirth's Ghost

    June 5, 2009 at 9:25 am Reply

    Thanks! Hopefully, it won’t be one of those feeds that gets habitually ignored. 😉

  4. Niklaus Wirth's Ghost

    June 5, 2009 at 9:25 am Reply

    Thanks! Hopefully, it won’t be one of those feeds that gets habitually ignored. 😉

  5. Why are both

    INJECTEDMEMBERS and CUSTOMERORDERSERVICE

    capitalized? I’m guessing its a standard way of blogging that means trivial or unimportant code?

  6. Why are both

    INJECTEDMEMBERS and CUSTOMERORDERSERVICE

    capitalized? I’m guessing its a standard way of blogging that means trivial or unimportant code?

  7. Actually, they show up as all UPPER case in Internet Explorer but all lower case in Firefox which I’m guessing has to do with the javascript plugin I use for code display. Both of those types should be PascalCased I think as in CustomerOrderService.

    Rather strange behavior of the plug in though, I’ll have to look into it.

  8. Actually, they show up as all UPPER case in Internet Explorer but all lower case in Firefox which I’m guessing has to do with the javascript plugin I use for code display. Both of those types should be PascalCased I think as in CustomerOrderService.

    Rather strange behavior of the plug in though, I’ll have to look into it.

  9. Brett –

    It’s funny how often these scenarios come up. I usually end up with a ISettings class that end up implementing for this sort of thing, then use the methods you describe here to build it up, or use .config xml values if that is an option. Either way (using a settings class or passing a param) you end up abstracting your config values from the standard .net .configs which makes your classes more mobile and easier to test. Good call.

  10. Brett –

    It’s funny how often these scenarios come up. I usually end up with a ISettings class that end up implementing for this sort of thing, then use the methods you describe here to build it up, or use .config xml values if that is an option. Either way (using a settings class or passing a param) you end up abstracting your config values from the standard .net .configs which makes your classes more mobile and easier to test. Good call.

Leave a Reply

Your email address will not be published. Required fields are marked *