Dependency reversal principle dip and ASP. NET Core Project structure

The DIP dependency reversal principle Dependency inversion Principle is defined as follows:

high-level modules should not be dependent on low-class modules, they should all rely on abstraction .

Suppose the controller relies on the instance/implementation of repository, not interface:

In this example, the controller is a high-level module, and the repository is a low-class module.

But by definition: high-level modules should not be dependent on low-class modules, they should all rely on abstraction . So how do we solve this problem?

That is to extract a interface from repository, called IRepository, which is an abstraction:

In this way, the controller relies on irepository, so the high-level modules do not depend on the low-level modules, they are now dependent on abstraction.

So what's the good of doing this? Why use dip principle?

The answer is: reduce the impact of change .

Look at the first picture:

In one respect, if Repository is recompiled, the controller must recompile, i.e. all classes dependent on repository will be recompiled.

After using the dip principle:

We can make a lot of changes in repository, but none of these changes will affect the controller, because the controller is not dependent on this implementation.

As long as irepository this interface or contract contract does not change, controller will not be affected. This could also have less impact on the overall project.

Interface stands for "What", and the realization represents "how to achieve".

Interface is seldom changed once it has been completed.

For the project structure of ASP. NET core using the Repository+unitofwork mode, a little bit of code friend may have a bit of a wrong understanding, which might divide the structure of the ASP. NET Core project:

In this way, this is actually the case:

High-level packages/modules depend on low-level packages/modules.

Also violates the dip principle, so if you want to follow the principle, you need to introduce a new module:

Put all the abstract related classes in the core.

This satisfies the dip principle.

The project structure of ASP. NET core should be this idea:

Because models is the core content of the whole project, it is also placed in core.

Of course, can also be divided into several projects to achieve dip, but not necessarily according to a number of items separated by the implementation of the dip, or to see their dependency relationship.

Dependency reversal principle dip and ASP. NET Core Project structure