Foreword by Chris Tavares
.png "patterns & practices Developer Center")
The set of ideas that later congealed into the Unity container were originally conceived while I was working on the Web Client Software Factory project. Microsoft’s patterns & practices team had been using the concept of dependency injection for several years at that point, most famously in the Composite Application Block (CAB). It was also core to the configuration story in Enterprise Library 2.0, and was again central when we started tackling composite applications for the web (a library that became known as CWAB).
Our goal had always been to promote the concepts of Dependency Injection as a way to build loosely coupled systems. However, the way p&p approached DI at the time was different then how we think about it now. Instead of a single reusable container it was felt that the DI implementation should be specialized to the system in which it was being used. We used a library called ObjectBuilder, which was described as “a framework to build DI containers.” This would in theory let us write a container per project that did exactly what we wanted.
A lofty aspiration, but in practice it didn’t work out so well. ObjectBuilder was a highly decoupled, abstract set of parts that had to be manually assembled. Combined with a lack of documentation it took a lot of time to understand what needed to go where and how to put it together into something useful. That turned into time spent writing, debugging, and optimizing the DI container instead of working on our actual project requirements.
It got even more fun when somebody wanted to use CAB (which used one DI container based on one version of ObjectBuilder) and Enterprise Library (with a separate container based on a different version of ObjectBuilder) in the same project. Integration was very difficult; just dealing with referencing two different versions of ObjectBuilder in the same project was a challenge. Also the one-off containers led to one-off extensibility and integration interfaces: what worked in Enterprise Library was useless in CAB and vice versa.
It finally came to a head when we’d just spent yet another week near the end of the Web Client Software Factory project fixing a bunch of bugs in CWAB: bugs that looked very similar to ones we’d fixed before in CAB. Wouldn’t it be nice, we asked, if we could just have one container implementation and just use it instead of writing them over and over again?
From this frustration grew Unity. The Enterprise Library 4.0 team put the Dependency Injection Application Block (as Unity used to be known originally) on the product backlog. Our goals for the project were straightforward. First, introduce and promote the concepts of dependency injection to our community, unencumbered by a lot of low-level implementation details. Second, have a core container with an easy to use API that we, other teams at Microsoft, or anyone whose organization was uncomfortable using the available open source projects (for whatever reason) could just use. Third, have a variety of extensibility mechanisms so that new features could be added by anyone without having to rip open the core code.
In my opinion Unity has succeeded on all these goals. I’m particularly proud of how we affected the .NET developer community. Unity quickly became one of the most commonly used DI containers in the .NET ecosystem. More importantly, other DI container usage has increased as well. Unity introduced DI to a new set of people who would have otherwise never heard of it. Some of them later moved on to other containers that better suited their needs. That's not a loss for Unity: they’re using the concepts, and that’s the important part.
There’s not a whole lot of evangelism published for DI containers anymore. In my opinion, this is because DI is no longer an “expert technique”: it’s now part of the mainstream. When even frameworks from Microsoft (ASP.NET MVC and WebAPI in particular) come with support for DI built in, you know that a concept has reached the core audience. I think Unity had a very large role in making this happen.
I’m thrilled to see this book published. For the first time, there’s one place you can look for both the concepts of DI and how to apply those concepts using the Unity container. And there’s coverage of the extensibility story, something I always wanted to write but never seemed to get started. I don’t need to feel guilty about that anymore!
Read the book, embrace the concepts, and enjoy the world of loosely coupled, highly cohesive software that DI makes so easy to build!
Chris Tavares
Redmond, WA, USA
April 2013