Dependency Injection through Interface and project structure

Question

This question is a bit difficult to explain but I will try my best.

I have a project where I have to make an UI which gets data from a third party service and does deserialization and some thread management work.

Now my project structure is under one solution in visual studio:

Project A : The UI

Project B :The API to get data from third party service

Project C: The Thread Manager API

Note: Project B has an IB interface and C has an IC interface to help dependency injection. projects B and C will be used by other teams in future.

Project A is using both IB and IC interfaces for dependency injection.

Now I will state my understanding of IOC : DIP says a high-level module should not depend on low-level module and both high-level and low-level module should depend on an abstraction. If you want to prevent the changes in high-level module on changing of low-level module you need to invert the control so that low-level module will not control the interface and creation of objects that the high-level module needs.

According to the above definition both the IB and IC interfaces should be defined in project A right? If they are in project A then how will other teams use IB and IC interfaces? Do I make another separate project for storing the interfaces?

Answer 1

Consider the following example project organization for your scenario:

Project A: Bootstrapper, in charge of running the application, configuring DI and setting up the UI (this could also go in a dedicated Bootstrapper project decoupled from the app and UI). Knows B, C, D, E, F

Project B: the UI (or as many projects as required to make it modular). Knows C

Project C: business logic (gets data from a third party service and does deserialization and some thread management work). Knows D

Project D: interfaces, containing IB and IC (they could also have separate dedicated projects).

Project E: The API to get data from third party service Knows D

Project F: The Thread Manager API Knows D

Notice the decoupling from the UI and the implementation through the business logic layer. This way, you can switch the implementation details without having to change either the business logic or the UI. Also, if your business logic varies, the impact is minimized.

Regarding DI, the bootstrapper project is the only one that has the whole picture, the rest should just use interfaces that the container set up by the bootstrapper will resolve (i.e. inject) for them.

Answer 2

According to the above definition both the IB and IC interfaces should be defined in project A right?

No. You should replace the term 'module' with 'class'. In that case it starts to make more sense:

high-level [class] should not depend on low-level [class] and both high-level and low-level [classes] should depend on an abstraction.

To be able to do dependency injection correctly, it doesn't matter in which assemblies those classes and abstractions are located. When the project gets bigger (i.e. multiple millions of lines of code, one or multiple teams working on it), it becomes important to adhere to the Principles of Component Design.

In your case, since both assembly A and B use interface IB, and assembly A depends on assembly B, IB can never be located in assembly A, since that would case a circular reference in the assembly. You will either have to place IB in assembly B or in a new assembly that both A and B refer to.