When using Dependency Injection, is it expected that an assembly implementing a "Composition Root" should reference all dependent assemblies directly?

Question

Is it safe to assume that in order for "Composition Root only" Dependency Injection to occur, the assembly containing the composition root (usually the entry assembly) must contain project references to all projects of a given application? Please note that in this case I'm assuming that late-bound type resolution will not be used (i.e. XML configuration with unity or the attributed model in MEF.)

I've been told by multiple sources, including @Mark Seemann, that using a DI container as a service locator is an antipattern and it is in violation of the spirit of Martin Fowler's definitions of the Dependency Injection Pattern.

Consider the following sample Layer Diagram below. The Clients represent a set of head projects for Windows Desktop, Windows Store, and Windows Phone 8. (in this case let's assume that they are all C# projects using WPF, Jupiter, and the Windows Phone Silverlight Implementation respectively for UI design.) In each case they are relying on a few .NET portable subsets in the Application layer. Each component of the Application layer is independent of one another, and all are dependent on the Core layer (or the domain layer.) This same Core layer is also depended upon by the clients themselves.

If we assume that each application in the clients layer implements its own composition root, and that the composition root is implemented using a similar method in each system, then using xml.config files is inappropriate (for instance, windows store and windows phone 8 do not use external config files like .NET applications do with app.config.) Therefore the next best option is to use Code as Configuration. Using Code as Configuration however requires access to concrete types and therefore reference dependencies available to the composition root must be of the complete set of dependencies.

Am I missing something? Is there a better way to uncouple the dependencies here or is this a desirable trait for the application host assembly?

Answer 1

The benefits of DI are mainly for the code, not for the assembly. It matters little where the Composition Root (CR) is, it does matter that your code is not coupled to a concrete type so it can be reused.

The CR can be in the client or in its own assembly, that won't affect your actual code using DI. The only difference is what assemblies are referenced by the CR assembly.

So, it's up to you where you put the CR, personally I'd put it in the client, the fact that your objects takes abstractions as dependencies is what counts. As long as the object doesn't know about the DI Container i.e it doesn't use the service locator pattern, your code is decoupled.