Ioc/DI – Why do I have to reference all layers/assemblies in application’s entry point?

by

If I wasn’t using a DI container, I wouldn’t have to reference EntityFramework library in my MVC3 app, only my business layer which would reference my DAL/Repo layer.

Yes, that’s exactly the situation DI works so hard to avoid 🙂

With tightly coupled code, each library may only have a few references, but these again have other references, creating a deep graph of dependencies, like this:

Deep Graph

Because the dependency graph is deep, it means that most libraries drag along a lot of other dependencies – e.g. in the diagram, Library C drags along Library H, Library E, Library J, Library M, Library K and Library N. This makes it harder to reuse each library independently from the rest – for example in unit testing.

However, in a loosely coupled application, by moving all the references to the Composition Root, the dependency graph is severely flattened:

Shallow Graph

As illustrated by the green color, it’s now possible to reuse Library C without dragging along any unwanted dependencies.

However, all that said, with many DI Containers, you don’t have to add hard references to all required libraries. Instead, you can use late binding either in the form of convention-based assembly-scanning (preferred) or XML configuration.

When you do that, however, you must remember to copy the assemblies to the application’s bin folder, because that no longer happens automatically. Personally, I rarely find it worth that extra effort.

A more elaborate version of this answer can be found in this excerpt from my book Dependency Injection, Principles, Practices, Patterns.

More Related Contents:

  1. Why not use an IoC container to resolve dependencies for entities/business objects?
  2. Is there a pattern for initializing objects created via a DI container
  3. Why do I need an IoC container as opposed to straightforward DI code? [closed]
  4. What is a composition root in the context of dependency injection?
  5. Inversion of Control vs Dependency Injection
  6. Inversion of Control < Dependency Injection [closed]
  7. Dependency injection through constructors or property setters?
  8. Comparing Castle Windsor, Unity and StructureMap
  9. Which Dependency Injection Tool Should I Use? [closed]
  10. MEF (Managed Extensibility Framework) vs IoC/DI
  11. Resolving HttpControllerContext with Castle Windsor
  12. Windsor castle Injecting properties of constructed object
  13. Dependency Inject (DI) “friendly” library
  14. Windsor – pulling Transient objects from the container
  15. Dependency Injection vs Factory Pattern
  16. How do I effectively design my application where most classes depend on ILogger?
  17. Avoiding all DI antipatterns for types requiring asynchronous initialization
  18. How to remove unit of work functionality from repositories using IOC
  19. Dependency Injection and IDisposable
  20. Understanding IoC Containers and Dependency Injection
  21. Dependency Injection – new instance required in several of a classes methods
  22. When are .NET Core dependency injected instances disposed?
  23. What is the purpose of the getter methods in Components in Dagger 2?
  24. How can I register a generic decorator using Castle Windsor?
  25. When to use Dependency Injection
  26. Passing constructor arguments when using StructureMap
  27. How to use Castle Windsor with ASP.Net web forms?
  28. Net Core Dependency Injection for Non-Controller
  29. How to integrate IoC Membership provider with ASP.NET MVC
  30. How do I control MembershipProvider instance creation/lifetime?

Leave a Comment