Ouch, this turned into a long boring post. Here’s a tl;dr: “Unity was slow and clumsy, I couldn’t find an alternative that I really enjoyed so I wrote my own container. It’s on NuGet and github!”
Since being sold on IoC and Dependency Injection around 2008 I’ve been using Unity as the container-of-choice. Why? Well, why does anyone use Unity? Because Microsoft wrote it and it has everything you could possibly ask for in a container. Well, except speed of course. And ease of use. And some way of understanding what the heck is going on behind the scenes. But, those where realizations that kind of crept up on me, and once they did I had gotten so used to them that I didn’t really mind them too much.
Then a few months ago I started setting up yet another web service project and started thinking that maybe I should look around a bit before just doing what I always do. I set up a couple of simple goals I wanted a new container to fulfill:
- Easy to use and troubleshoot. In Unity whenever someone made a mistake with a registration, more often than not they had to go find me to help them find the problem.
- Fast. In this project in particular, speed is of the utmost importance. And I really mean that. Every fraction of a millisecond actually counts.
- Simple. Most often we only use the basics of a DI container, we simply don’t need tons of features.
Quite early I heard about Funq and I immediately fell in love with the idea of specifying a factory method instead of relying on reflection. First of all, it is of course blazingly fast. But more importantly a lot of common errors, such as adding a new parameter to a constructor without telling the registration about it, are all of a sudden found at compile-time instead of at runtime.
So, why didn’t I just use Funq (or Munq, a project with pretty much the same ideas as I had)? Why did I go ahead and write my own version? Well, the most obvious reason is of course – because I felt like it. But also, Funq seemed to be a bit more bloated than I needed (among other things it has a lot of strange code-genned overloads and stuff). Even Munq has quite a bit of code which definitely might make it easier to get started with (such as automatic registration), but it also makes it a little less transparent and a little more tricky to troubleshoot.
What really tipped me over though was that one of the biggest complaints I hear all the time about Unity is that it is impossibly to debug your way through a program when so much of it is put together in an assembly that you cannot easily step into. Sure, the code is available and it is quite possible to set it up on a symbol server or something similar, but having the code right there in your project would make it oh-so-much easier for everyone involved.
Aaanyway.. Petite.Container and Petite.Container.CommonServiceLocator are now found on NuGet (together with Petite.Repository.Domain and Petite.Repository.Data which I’ll try to write a little about some other time). And all the code with some unit tests etc is on github. Feel free to use it, but be aware that these are early bits not yet tried and tested in production (they will be quite soon though).
