Ioc

Introduction I have been evangelizing the use of IoC for a number of years. Frequently the newly converted ask the following two questions: Which container to use? Which is fastest? My answer to the first is almost always the one you choose, and for the second question I refer them to Martin From’s IoCBattleweb page. I wont get into the reason for my answer to the first question in this post (I will save that for another day).

A few years ago I wrote Type Tracking Extension for Unity and Extending and Demonstrating the Type Tracking Extension for Unity, and while I have been using Autofac more, I felt this code was due for a slight update. Given the ease of creating a NuGet package for Caliburn.Micro.Autofac (see Introducing Caliburn.Micro.Autofac), I thought that I could give some Nuget love to the Type Tracking Extension for Unity. What’s Changed Obviously, if I am working on some changes, I might as well bring the code up to date.

I really like MEF and I really like proper IoC containers (let the flames begin). I do not think they are mutually exclusive, but best suited for different goals. I consider MEF to be a great way to perform macro level componentization. In other words, it is a way to wire up components that are physically in different assemblies, but it is not well suited for the micro level componentization in which I need to wire up my dependencies within my application.

Recently, I have received a few requests for some changes and an example for my Type Tracking Extension for Unity. This post is to address those requests. Of course, all of the source code for this post is added to the GitHub project Unity Extensions. Part One – Extension Methods for the Type Tracking Extension The number one request I have received, and my own number one issue with using the Type Tracking Extension, is the verbosity of each method call.

In my recent post, IoC Challenge – Multiple interfaces to the same singleton instance, I posted an IoC challenge to the community. I also mentioned that on the Ninject discussion groups, a suggestion was posted on how to solve this using Ninject. Today, I decided to try out that suggestion, and I have to admit, it is quite elegant so far. Here is the source code used. First, the interfaces.

I have an IoC challenge that I am currently trying to work through. I have a series of classes that implement more than one interface, with the lifetime of the class needing to be a singleton, and I really don’t like the idea of falling back on custom instantiation code along with potentially custom lifetime management code to make this work. Sound confusing? Here is the model I am trying for.

Edit: Source code posted to [Hazware Unity Extensions on GitHub] My personal inversion of control container is Unity. However, I occasionally find myself looking for functionality from the other .NET IoC containers I have used, such as Ninject and Castle Windsor. Here is the code that came out from trying to solve this need. I was working on some Unit of Work code for NHibernate and I found the need to query the container to check if a type was registered.