A simple example
Let´s say I´ve got the following solution structure in Visual Studio:
- Unity.Model– has the contract/interface ICustomerServices
- Unity.Infrastructure – has the production implementation of ICustomerServices
- Unity.Test– has the unit test implementation of ICustomerServices
- Unity20 – has the unity configuration file and calls into the container
In this example there is only one interface and two implementations of that interface but imagine that we had ten or twenty interfaces. The problem with older versions of unity was that in the configuration file you started out with aliases for the interfaces and the implementations and then hooked them up in the container.
With many interfaces and implementations there was a lot of configuration to do and also, you had to set up every instance you wished unity to resolve in the configuration file.
Sometimes you´d forget to do that and the container threw an error when we resolved the type.
In short the configuration file easily got cluttered and unity became hard to maintain.
With unity 2.0 we now have some new options, let´s explore them:
The mixed approach
With the new unity configuration file we can now register namespaces and assemblies which unity will then search through when we resolve a type from the container.
As you can see I have added the namespace Unity.Model.Contracts and the assembly Unity.Model to the container (these are new options).
Inside the Unity.Model assembly I have placed all my contracts/interfaces inside the Contracts folder (which will also be the namespace).
I still have aliases for the implementations (prod and test) which I have named CustomerServices. Comment out/in the one to use at the moment.
In the container I register a mapping between ICustomerServices and CustomerServices although I haven´t told unity (via an alias) that I have a type called ICustomerServices. This is the new cool stuff; unity will look inside the Unity.Model assembly for a type called ICustomerServices inside the namespace Unity.Model.Contracts…nice!
The automatic approach
Given the situation above there can still be a situation where we will get a lot of aliases. Let´s go for an altogether automatic approach and let unity take care of the type lookup for us.
In this example I haven´t at all told unity what ICustomerServices and CustomerServices are…I just let unity know that it can search through a couple of namespaces and assemblies.
The only thing I have to change when going between prod and test is the namespace and assembly…pretty nice.
Note: For this to work we have to use the same type name in prod and test since we are not using aliases. Normally you might want to name the test instance CustomerServicesMockup or something…not a big deal though.
Finally, using unity to serve me up with an implementation of ICustomerServices looks like: