0

I have a problem with fully understanding DI. Let’s assume

  • I have a deeply nested application (10 Layers)

  • Each layer is designed against an interface. e.g.: class Layer3 : InterfaceLayer3 {….}

  • Each layer gets it’s dependencies to the next layer injected via constructor-injection. e.g.: Layer3(InterfaceLayer4 instanceLayer4) {….}

  • Each layer has its own Assembly. All interfaces are separated in their own assemblies (*.dll).

If I look on the class-diagram of my application it looks great: Minimal dependencies !!!

But, I have to create the objects for injection somewhere. I do this via factories at the composition-root, close to “void main(void)”. The factories are in a “Factories.dll”.

If I look on my class-diagram again, I observe that my “Factories.dll” creates a dependency-hell: It depends on all layers.

My question: It seems DI solved my dependency-problem for my application-code, BUT I just transferred the problem now to another place: "Factories.dll". What is wrong with this argument?

Novaterata
  • 4,356
  • 3
  • 29
  • 51
TomFan
  • 11
  • 1
  • 3
  • 5
    My first question is why you have a 10 layer application. – Steven B. Apr 26 '19 at 00:07
  • 1
    "With enough layers of abstraction you never need to write the actual code." - No architect ever – David Apr 26 '19 at 00:09
  • @Steven: This was just an example. My problem exists even for 2 layers – TomFan Apr 26 '19 at 00:17
  • 1
    But now can you individually test each class? Can you easily swap out a specific implementation without needing to change other layers? – mason Apr 26 '19 at 00:18
  • Why would you do something that you don't want to do??? Clearly you have no reasons to make single assembly depending on all other assemblies... but you created one with all dependencies anyway... (Also showing what DI container you are using so it can't load all assemblies you need using some declarative way would help ) – Alexei Levenkov Apr 26 '19 at 00:28
  • @mason: Yes of course. Testing works great, this was my intention. But my colleagues say: Hey guy your "factories.dll" is a dependency-hell. What should I answer to them? – TomFan Apr 26 '19 at 00:30
  • @Alexei: If I understand right, you say: Do it declaratively via a DI-Container. But I find some threads here "DI-Container vs Factories" which more or less say: "It's a matter of taste" and not a real benefit to use DI-Containers. – TomFan Apr 26 '19 at 00:37
  • DI isn't meant to remove the need for dependencies. Your application will depend on as many things now as it did before, or even more. What it's meant to do is cause each piece of code to depend on its dependencies by interface instead of specific implementation. – mason Apr 26 '19 at 00:39
  • "your "factories.dll" is a dependency-hell. What should I answer to them?" - you can answer "I like it that way!"... But you have not explained *why* did you do that... There is no requirement so far in your post that demonstrates the need for all factories to be in the same assembly... And indeed none of DI container I know depend on all possible assemblies... nothing stops you to write uber factory that just loads all assemblies and create instances either directly or through local factories if you like factories over DI containers... – Alexei Levenkov Apr 26 '19 at 00:46
  • 1
    (when you are reinventing the wheel it help to look at existing once,... including [square wheel](https://www.youtube.com/watch?v=Ppcgr0zHyx0) once :) ) – Alexei Levenkov Apr 26 '19 at 00:48
  • _only transfer_ : It is supposed to transfer them where they belong. So __yes__ to _transfer_ but __no__ to _only_. – TaW Apr 26 '19 at 09:29

1 Answers1

1

You shouldn't concern that Composition Root (app entry point) referenced many 'application-code' items (interface & implementation assemblies) because it has been achieved the main goal - libraries/frameworks depend on just required abstractions.

So that libraries/frameworks can be easily configured, tested, reused, maintained, delivered as packages etc

If you are concerned about the mess/complexity of configuration in Composition Root then can be used Module (it is provided by many IoC-containers, for example Autofac Module) that group related configuration items.

vladimir
  • 13,428
  • 2
  • 44
  • 70