When to use dependency injectors such as Ninject

Question

Problem

I have some problems to understand when and where exactly in my code I should use dependency injectors such as Ninject.

the code

Say, for example, we have the following code:

//WITHOUT NINJECT: IMailSender mailSender = new MockMailSender(); //WITH NINJECT: IMailSender mailSender = kernel.Get<IMailSender>(); 

This is not an dependency injection, so it makes sense to use Ninject in this scenario?

Another example shows how my code really got messed up with the dependency injector:

  public void CalculateRevenueRecognitions(IContract contract) { //WITH NINJECT var kernel = new StandardKernel(new DefaultModule()); var arguments = new List<IParameter> { new ConstructorArgument("amount",contract.Revenue), new ConstructorArgument("date", contract.WhenSigned) }; contract.AddRevenueRecognition(kernel.Get<IRevenueRecognition>(arguments.ToArray())); //WITHOUT NINJECT: contract.AddRevenueRecognition(new RevenueRecognition(contract.Revenue, contract.WhenSigned)))); } 

Question

When should I use the dependency injector?

• when injecting a constructor, entering parameters, etc.
• when creating an object (do dependency injectors make the replacement of creating a classic object new?)
• - others?

When should you not use dependency injectors?

Answer 1

The basic premise is not to rely on specific classes (for example, you talked about new classes) and implement implementations (via interfaces). It depends on the specific task that you perform and under what conditions (Windows service, WCF service, Asp.Net), but in most cases you have an interface with all the methods that you want to publish publicly, for example

 public interface IBar { void DoStuff(); } 

Then you bind them to a specific class using Ninject i.e.

  Bind<IBar>().To<BarClass>(); 

So, when you start Ninject jumps and gets a customized implementation. Plus, your configuration is configured, so it’s very easy to switch to another implementation while it implements the interface. Therefore, if you had a different class that you wanted to use instead of BarClass, you could just reinstall it. Ie

 Bind<IBar>().To<NewBarClass>(); 

Therefore, when you need to use this NewBarClass, you must pass it this way

 public class UserOfNewBarClass { public UserOfNewBarClass(IBar newBarClass) { } // Use the IBar interface } 

In addition, you can mock interfaces when testing, which means that you can isolate individual concrete classes and test them in complete isolation. You can do more complex things that you can learn later, like a binding based on property values ​​and a conditional binding to what you enter.

For entry points, refer to these

WCF - http://www.aaronstannard.com/post/2011/08/16/dependency-injection-ninject-wcf-service.aspx

MVC - http://www.shahnawazk.com/2010/12/dependency-injection-in-aspnet-mvc-3.html

Windows Service - Using Ninject with a Windows Service

It’s hard to understand at first, but the Container (in this case Ninject) determines which implementation should be entered based on the binding you specified. The ultimate goal is to implement everything your class needs in order to execute its methods so that you can test it in isolation (this also helps to keep the class clean and uncluttered). The preferred way is to inject through the constructor, since the class will have all its dependencies when it is created. Entering properties is, of course, possible, but, as with properties, you cannot guarantee that it has been set.

Answer 2

In the past, I have heavily used injection injection frameworks. Hell, I even wrote one (which performs registration and resolution of lightyears faster than Ninject, although I was happy to borrow its fascinating unit test model Ninjas, KiteShields Shuriken, etc.)

Nowadays, I almost never use the dependency injection infrastructure. Because if I found out one of the uses of (heavy) frameworks, this is the following:

you have a technological problem. You are looking for and experimenting with frameworks to help solve this problem. you select it and use it everywhere.

You now have 2 problems. your dependency injection infrastructure just made you depend on all dependency on your entire code base.

There is an excellent presentation of SkillsMatter by Greg Young ( http://skillsmatter.com/podcast/agile-testing/simple-is-better ) as part of frameworks with statements and opinions that may seem a little extreme but quite a few of them, I learned the hard way I agree with him.

Answer 3

The fact is that now I can not imagine a scenario in which I would just use dependency injection myself. I am more familiar with situations where you use Inversion of Control (an IoC container that uses DI). In such cases, your code is actually very clean, because you do not need to call the injector for instances. The IoC container will do this for you.

So, I would have thought if not using IoC / DI instead of using only DI. In the end, many successful frameworks use this combination, not just one of the pair (assuming they use DI at all, because there really is another template that can be combined with IoC).

Answer 4

If you want to learn about dependency injectors and when to use them, check out this article. I wondered the same thing a few ago, and this article helped me a lot.

Dependency Injection - Martin Fowler