4

I have just started learning about Dependency Injection (DI) and its types in C#. I noticed that in almost all articles, the first two types of injection mechanisms mentioned are same, i.e., Constructor Injection and Property/Setter Injection.

But the third one is different in many articles - Some authors have mentioned "Interface-based Injection" as the third mechanism and some have mentioned "Method Injection". I may be wrong in my understanding of the same and they both could be the same thing, but just for my clarification, would like to know if there are any specific differences between the two of them?

Thanks in advance.

References: http://www.dotnettricks.com/learn/dependencyinjection/implementation-of-dependency-injection-pattern-in-csharp

http://www.c-sharpcorner.com/UploadFile/ff2f08/dependency-injection-pattern/

Abhishek Guha
  • 154
  • 1
  • 9
  • Maybe stick to reading more authoritative articles. You only need to worry about Constructor or Property/Setter injection. – Ian Mercer Jan 30 '18 at 08:06
  • I guess you could call this method injection: `public void Foo(Action func) { func(); }`. `Action func` is your dependency and you can provide any implementation you want. – FCin Jan 30 '18 at 08:06
  • 1
    Interface and "Method" Injection are the same. https://en.wikipedia.org/wiki/Dependency_injection#Interface_injection –  Jan 30 '18 at 08:32

1 Answers1

5

There are three basic DI patterns that describe how to inject a dependency:

  • Constructor Injection, is the act of statically defining the list of required Dependencies by specifying them as parameters to the class's constructor.
  • Property Injection (a.k.a. Setter Injection), statically defines an optional dependency using a property, when there already is a good Local Default.
  • Method Injection, allows supplying a consumer with a dependency by passing it in as method parameter, where this method is called outside the Composition Root

Martin Fowler however alo defined Interface Injection. This might seem like another form of DI, but it is in fact just a form of either Property Injection or Method Injection, where the property or method is part of the class's Abstraction. Interface Injection is to my knowledge not commonly used terminology.

Dependency Injection Principles, Practices, and Patterns describes that injection methods should always be placed on the Abstraction. When such injection method is implemented solely on the implementation, it means only the Composition Root can access them, but the book states:

Method Injection is unsuited to be used within the Composition Root. Within a Composition Root, Method Injection can be used to initialize a previously constructed class with its Dependencies. Doing so however leads to Temporal Coupling and is for that reason highly discouraged (§ 4.3.2).

Property Injection on the other hand, is typically solely used on the implementation rather than the Abstraction. That's because in the case of Property Injection it is the Composition Root that will set that dependency.

Interface Injection, as Fowler describes it, seems to be primarily used to initialize a component, but as stated above, that leads to Temporal Couping and should therefore be prevented. Either use Constructor Injection or use Method Injection without storing the dependency.

To get a better understanding of DI, you should read the freely available chapter 1 of that book.

Steven
  • 166,672
  • 24
  • 332
  • 435
  • _"there is `no such thing` as `Interface based Injection`"_ - Incorrect. software engineering actually [defines it](https://en.wikipedia.org/wiki/Dependency_injection#Three_types_of_dependency_injection) –  Jan 30 '18 at 08:36
  • 1
    @MickyD: I stand corrected. Martin Fowler indeed [defines the term](https://www.martinfowler.com/articles/injection.html#InterfaceInjection). However, do note that what he describes is actually either Setter Injection or Method Injection. Or more precise, Method Injection where the injection method is defined on the Abstraction. – Steven Jan 30 '18 at 08:45
  • 1
    Yes. To be honest, I'm not terribly fussed with what they (wiki) essentially define as a _member that takes an argument to set the dependency_. I agree with you that in that regard it is no difference to a _setter_ considering no business logic is described in the former. I was kinda hoping _interface_ was actually like as per examples in Windows Shell or Windows MMC programming where the interface defines a behaviour not just a dependency. Oh well. ;) +1 my friend –  Jan 30 '18 at 08:53
  • 1
    In [our book](http://manning.com/seemann2/) Mark and I describe how an _injection method_ should _never_ store its incoming dependency. This leads to Temporal Coupling. Instead, the method should just use the dependency. From that perspective, Fowler's a great example of what _not_ to do. :) – Steven Jan 30 '18 at 08:57
  • Ah excellent. I shall look into your book. Wishing you well :) –  Jan 30 '18 at 09:05