Autowireup Extension for Unity

Introduction

I was looking out for a new Inversion of Control container for an upcoming project that had to support configuration via Xml to allow easy customisation of a web solutions without requiring a recompilation. I used to work with Spring.NET and StructureMap in previous projects - StructureMap really annoyed me due to the lack of concise documentation, Spring.NET totally rocked, however the project appears to be dying due to lack of development in the past months.

The two frameworks that came to my attention where Castle Windsor and Unity. Castle is a well known container with lots of backing in the open source community and a wide range of support and functionality. Unity is developed by Microsofts Patterns & Practices group and appears to see lot's of positive feedback as well. Unity is more focused in it's feature set and sice we heavily rely on the Microsoft stack anyway i wanted to take a closer look.

One of the requirements we have is, that the project consists of a core and customizations hooking into the core. For instance customisations may be new web forms, replace or otherwise configured infrastructure and so on. A core requirement is, that the core has to be upgraded without breaking customisations. My vision of how to achieve this, is to have two Xml configuration files, one for the core  and one for the customisations that are merged together. Here is an example.

Standard configuration


<container>
  <register type="IType1" mapTo="Type1" />
</container>

Custom configuration


<container>
  <register type="IType1" mapTo="CustomType1" />
</container>

So in this case the custom configuration would override the standard one when being merged together. An important decision when dealing with IoC is, which kind of injection to choose. Mose commonly used are constructor injection and property injection. Constructor injection is somehow problematic here, let's assume, that CustomType1 inherits from Type1. In this case at the point, where you add a dependency to Type1 (e.g. due to refactoring) you implicitly break CustomType1 since you do not pass the dependency down the constructor chain. You could drive a concept to pass down the IOC container as a parameter, however this somehow is against the original idea of IoC and makes things like testing extremely cumbersome.

So let's say instead of customer injection we're going with property injection.

Standard configuration


<container>
  <register type="IType1" mapTo="Type1">
    <property name="Collaborator1" value="Collaborator1Object" />
  </register>
</container>

Custom configuration


<container>
  <register type="IType1" mapTo="CustomType1">
    <property name="Collaborator1" value="Collaborator1Object" />
  </register>
</container>

Again assuming, that CustomType1 derives from Type1, adding dependencies to Type1 will effectively break the application unless you add the new dependency to the custom configuration as well. You could go with an approach where you add a more sophisticated logic when merging the files that keeps the original collaborators from the standard configuration in place unless you explicitly overload them.

Spring.NET offers a much simpler approach called Autowiring. Autowiring uses convention to wire up dependencies. You can either use type or name based autowiring. With type autowiring, if you got a property of the type ICollaborator, Spring.NET searchs for a registration for the type ICollaborator and then injects it. With name autowiring, if you have a property with the name Type1, Spring.NET will search for a registration with the name Type1 and inject it. This saves alot of typing when sticking to the convention and remedies the above described problem. There appears to be some philosophical conflict in the IoC space about whether autowiring is actually a good thing, and neither Castle Windsor nor Unity support it out of the box. Castle Windsor appears to support autowiring by type, and has extension points to implement autowiring by name. For unity I did not find such a thing. In my case I wanted to go by name to be able to register multiple objects implementing the same interface, e.g. let's say you've got the interface ILoginProvider and the implementing classes UsernamePasswordLoginProvider, WindowsSsoLoginProvider and LdapLoginProvider.

The Extension

Though not too well documented, unity allows for plugging in extensions. In addition to imperatively adding extensions to the container, this is also possible via web.config/app.config.

Extensions have an initialisation method that allows to hook into the object creation process.

You can contribute so called "Strategies" that kick in at different points of the object creation/disposal lifecycle. The extension supports wiring up by name and by type by exposing two different kind of extensions.

It is important to know, that when you choose to wire up by type, you must not assign a name to the registrations. This is how unity handles stuff.

Final Words

I attached the source along with the binary dll to this post. Feel free to play around with it. I did not extensively test the solution so far. Please give me some feedback if you find it useful and working in your case.

UnityAutowireExtension-source.zip (365,97 kb)

UnityAutowireExtension.dll.zip (2,74 kb)

About the author

for comments and suggestions contact:

 

Month List