Codes can be downloaded here
In my last post, I showed a simple dependency injection using Castle Windsor. This time, I tinkered Microsoft Unity Framework and tried to find out how it faired against the former. There are nomenclature differences but the structure and code are fairly similar. It wasn’t a smooth coding though for I encountered a roadblock. The problem is on retrieving of the configuration section for Unity:
The message is misleading because the files have always been there and the solution is actually to install the assembly Microsoft.Practices.Unity.Configuration in the GAC. There is a discussion about this problem here. Unfortunately, I wasn’t able to make the other suggested solutions work. After the GAC install, the app configuration became
Take note that I needed to embed the version and the public key token which can be found when browsing the C:\Windows\Assembly folder
I don’t like these because I’m not sure if these values are portable. These just add headaches during deployment.
As I mentioned earlier, the difference are mostly confined to nomenclature. One thing to take note though is the attribute “type” in the node “type” which equivalent in Windsor is “mapTo”, not “type”.
Being a MS implementation, it’s no surprise that Unity uses BCL classes to do its chores. For example, in the initialization of the container, you use the System.Configuration.ConfigurationManager instead of some customized XML interpreter. This is a great welcome to programmers because it significantly lower the learning curve.
At this point, I still prefer Windsor over Unity. I’ve perused the documentation and found Unity to be a little verbose. I might be wrong on that but the roadblock I just experienced would probably justify my stand.
