Should I separate IoC binding seperation by project

Question

I am new at domain driven design architecture. My project solution is like this:

• Presentation(Web)
• ApplicationLayer
• QueryLayer
• QueryHandlerLayer
• DataLayer

I read from articles theese separations is doing to isolate jobs.

Presentation project references ApplicationLayer But does not reference QueryLayer,QueryHandlerLayer and DataLayer.

But I am using IoC container and bind types to interface.

• container.Bind(data interfaces).To(data classes);
• container.Bind(query interfaces).To(query classes);

I can do this on PresentationLayer. But now all projects will be add reference to presentation layer.

Is this an issue about architecture? Or May I separated IoC container binding for all layers?

Answer 1

Using DI is about composing applications. An application might have multiple layers, but they are still part of the same application and must be composed together.

The appropriate place to compose an application is in the composition root, which should be as close to the entry point of the application as possible.

There are basically 3 common recommendations for composing applications with multiple layers, and all of them are perfectly acceptable.

1. Don't separate the layers into physical assemblies.
2. Compose the application in the presentation layer, and reference all other layers from the presentation layer.
3. Create a separate composition layer that references all of the other layers.

For the 3rd option, you should keep in mind that the composition layer is supposed to drive, not be driven by, the rest of the application.

See this answer for the reasoning behind this referencing and why it is important that you do reference every library from the composition root to avoid tight coupling. Or, as mentioned, you could use late binding to compose your application without referencing the assemblies directly, provided your deployment script copies over the DLLs.

Answer 2

I think the biggest thing I have learnt in recent usage is that at the fundamental level, DI is about Injecting Dependancies. That's a pretty redundant description, so let me elaborate:

DI starts with design. Everything should have what it needs provided to it via a constructor, or factory of some sort. This is where Interfaces are your best friend. Once you have done this, most of the work is done. Assuming some of the projects are shared, you have now delegated out all of the work to whoever is using it. This is probably old news, however.

Next, if you are in control of the container, consider creating a default module, which in the case of Ninject is a, NinjectModule. Create one of these for each application layer. This will form the "instructions" so to speak, for the container at the highest level of your program to put all the pieces together.

This can all be loaded by reflection trickery of which there is plenty of information around, like this.

Then it is as simple as loading all of these binding "instruction manuals" into the composition root (usually in the application) and you're good to go.