I recorded a .NET Rocks! Show with Carl Franklin and Richard Campbell, called Unity and More! It is show #393 and will be available on November 11, 2008.
We talked about a lot of stuff but the focus was on the Unity Dependency Injection Container from Microsoft Patterns & Practices. Richard and Carl "surprised" me with the question, "Why choose Unity?" that I didn't get a chance to answer fully, so I thought I would throw out my 5 top answers in a post.
First some thoughts.
Is the Choice Technical Anymore?
My top 5 answers might surprise you as they are not technical in nature. Why? Because a year ago I would have been very opinionated from a technical standpoint as to why I preferred Castle Windsor, but not so much today. There are a lot more dependency injection frameworks that have great features now and have become much more mature, lessening the gap in functionality.
My opinion today is that you can get the necessary services from just about any of the more widely known containers: Castle Windsor, Spring.NET, StructureMap, Unity, Autofac, and Ninject. Although they have their strengths and weaknesses, if you keep dependency injection simple, which I believe you should, I personally think technically you can live with any one of them. In fact, the possibility of a Common Service Locator Library kinda suggests this idea.
Where they mainly differ is in component registration, extensibility, and integration with other tools. Therefore I think largely you will choose one DI Framework over another based on less technical reasons, like:
- You prefer one fluent interface or XML schema over another.
- You respect another developer who uses or develops a particular framework.
- You are a big fan of a certain 3rd party library that has wonderful integration with a particular IoC Container.
- Your client is insistent on a particular dependency injection framework.
- etc...
Extensibility Makes Features a Moving Target
The other interesting aspect is that all of the dependency injection frameworks worth their salt are very extensible. This means that even though out-of-the-box a container might not do XYZ, you can probably extend it to offer the functionality.
In fact, this goes back to my .NET Rocks! Show where I mentioned a story James Kovaks mentioned on his recent .NET Rocks Show. James described a situation where Jeremy Miller was giving a presentation at DevTeach and proudly announced during the presentation that StructureMap had a cool feature not available in Windsor. Oren Eini, who was attending Jeremy's presentation, added the same functionality during the presentation to Windsor in about 30 minutes without breaking a sweat. Now, of course, Oren is a coding guru, but it also shows the extensibility of these containers.
My Top 5 Reasons to Choose Unity Dependency Injection Container
I could go on about this, but let's get to the top 5 reasons why someone might want to choose the Unity Dependency Injection Container over the other containers.
1. Excellent Documentation
I am a huge fan of the documentation coming out of Microsoft Patterns & Practices. As you know, finding good documentation on anything open source is rare - very rare. This is not the case with Unity and other guidance packages and libraries coming out of Patterns & Practices. Their documentation not only shows you how to use Unity, but also introduces you to the concepts of dependency injection and Inversion of Control. It also explains the key scenarios with code samples on how to use Unity, and more importantly, is also upfront about when and when not to use Unity. And, yes, as new versions of Unity come out, the documentation is updated, too!
[ Aside: we do need some documentation on how to extend Unity which was left out of the Unity v1.1 documentation due to time constraints. Hopefully that gets added in the Unity 1.2 documentaion :) ]
2. Friction-Free Download
I am very comfortable with accessing the latest source code from a Subversion repository and re-building a dependency injection framework for the latest version, but seriously, this shouldn't be the norm. Most open source tools are notorious for staying in a perpetual beta or requiring you to go into the source code repository to access and build a version that isn't sanctioned as a "production release."
I am happy that Unity actually has production and supported releases that you can download friction-free. First there was Unity 1.0, then 1.1, and soon we will have Unity 1.2. All are supported and considered production ready. Unity can be downloaded as an installer ( msi file ) and optionally ( not required ) you can also access early bits via the source code tab on CodePlex. Nice.
3. Seamless Integration with Enterprise Library
If you are a big fan of Enterprise Library, you will enjoy the seamless, yet unobtrusive integration with Enterprise Library. Enterprise Library ships with Unity Extensions for each application block that will allow you to integrate those application blocks of your choice with 1 line of code. For example, integrating the Data Access Application Block with Unity is as simple as:
container.AddNewExtension<DataAccessBlockExtension>();
Note that there is no hard coupling here between Unity and Enterprise Library. It is all loosely-coupled and optional. If you don't want to use Enterprise Library, don't :)
4. Good Relationship with Software Factories and Guidance Packages
For those of you interested in the various guidance packages, software factories, and application blocks released by Microsoft Patterns & Practices, you can be assured that most of these will have out-of-the-box support for Unity. Various samples will also probably use Unity, making it easier for you to understand and deploy the guidance as well as learn from the samples. Prism is a good example of this.
You also, of course, find good integration solutions for non- P&P solutions, like the ASP.NET MVC Framework. There is a Unity ControllerFactory in MVCContrib.
5. Leverage Current ObjectBuilder Knowledge
For those of you who have developed expertise on ObjectBuilder or have applications using ObjectBuilder, the fact that Unity sits on top of a nice and shiny ObjectBuilder 2.x engine makes it easier for you to understand Unity as well as extend it. There is also a good chance that if you have built a custom container on the original ObjectBuilder that you can migrate your application to Unity.
Ceratinly if you have been using the Smart Client Software Factory and Web Client Software Factory you probably built up a decent understanding of how to extend ObjectBuilder. Leverage that current ObjectBuilder knowledge to your advantage.
Conclusion
I could go into some of the technical benefits of Unity, especially the new features we will be seeing in Unity v1.2 that makes it very attractive, but like I mentioned, I think the reasons for choosing are less technical and more have to do with the benefits mentioned above. See my Unity Tutorials and Unity Screencasts for more information on Unity.
Hope this helps,
David Hayden