For many years I have used Dependency Injection in the projects I have worked on professionally. At work we have standardized on Microsoft’s Unity package. Unity is great; I have nothing against it, but I wanted to learn more about how these IoC packages work under the hood and the dependency injection really takes. Turns out, with C#, it really doesn’t take much. The .NET framework includes reflection and allows you to dynamically create objects without much effort. To build an object, all you need to do is reflect into the constructors, pick one to use (in my case I did a greedy search finding the largest constructor I could use) and build the object. You have to recursively build the parameters to the constructor. Because recursion is happening, it doesn’t matter how complex you object is, it can have zero or a hundred constructor parameters, and each parameter can have their own dependencies. Recursion makes for a simple and elegant solution.
My next challenge, and this is something that I have used at work many times, was to make this work in the MVC framework. MVC relies on reflection and naming convention to build your controller objects with the HTTP requests, but the magic is that MVC knows exactly where to send the request and how to build the controller object it needs. But, have you ever said, gee, I really need a database connection in this controller, so I’ll just add it to the constructor because that will make testing really easy. MVC will puke on you because it is also using a dependency injection tool under the hood, a very very simple one and only builds parameter-less constructors. Good news, almost every piece (at least everything I have ever worked with) of MVC is extendable, including its simple DI code. MVC defines the IDependencyResolver interface for resolving dependencies, including controllers.