Question

Preface

I feel like there is a real possibility to shoot yourself in the foot when working with DI frameworks.
(My framework of choice is ninject so I’ll be using that in my examples.)

I’m going to step back for a second and look at the reason DI frameworks exists:
To prevent having to do DI by hand

Right so, in the spirit of Ninjects documentation, lets say we have a Dojo that creates Samurais. These Samurais are given an IWeapon when they are made.

class Samurai{
    readonly IWeapon weapon;

    public Samurai(IWeapon weapon){
        this.weapon = weapon;
    }
}

Now it is my understanding that the Dojo would use Kernel.Get<IWeapon>() when it creates a Samurai.

Woah
Didn’t I just couple my Dojo to the Kernel?
Also… How is it supposed to get the Kernel: DI, a singleton, service location?

I feel like we just swiftly defeated the purpose of DI because now I’m dependent on my DI framework. What happens if ninja’s are defeated and ninject dies too?

Question

How do we use DI without coupling to a DI framework?

Postface

I’m sure this question has been asked before however I couldn’t find anything. Please use the comments to post relevant questions so that we can pool the knowledge to figure out the best solution.

Answer 1

When doing Dependency Injection the trick is to have all your classes inject their dependencies through the constructor. This way you can let the Kernel build up a complete object graph for you from the root object.

This ‘root object’ however, is something that has to be resolved directly by calling kernel.Get<HomeController>() (if HomeController is the root object). So somewhere in your application you will have to call kernel.Get. It’s impossible to go without.

The trick is to minimize this to ideally a single line of code in the application and place this near the startup path. Probably close to the place where you registered your dependencies. The rest of the application stays oblivious to the use of any DI framework.

There are even integration packages for Ninject and other containers that allow you to remove that single line of code depending on which application platform you use. ASP.NET MVC for instance has great extendibility points that allow you to plug in a ControllerFactory that allows you to let that factory call kernel.Get for you.

How do we use DI without coupling to a DI framework?

There will always be some coupling, but ideally this should only be the startup path. All other code should be oblivious to the use of a container. There will still be a assembly dependency, but this dependency will only exist in the startup project, and not in your business layer.

look at the reason DI frameworks exists: To prevent having to do DI by
hand

To be more precise. DI helps making your application more maintainable. DI frameworks help making the startup path of your application (a.k.a. composition root) more maintainable.