0. Preface
In the previous articles of "asp.net core series", we briefly understood the relationship between routing, controller and view and the introduction of static resources, which gave us a basic understanding of the asp.net core mvc project. However, these are not the entire content of the asp.net core mvc project, and the rest of the content will be combined with the actual project to explain the knowledge for you. Now, let's get started.
1. Project Construction
Putting aside the previous project, now follow me to re-create a project, the first step is still to create a solution first:
dotnet new sln --name Template
Let me first introduce this project (referring to the entire project, not a separate asp.net core application). This is a template application for background management that provides common background system (administrator) functions, including employee management, department management, Role management and other functions.
Now back to the project, usually a project needs a model layer, a data providing layer and a web presentation layer. Then, we create three projects of Data, Domain, and Web in turn, where Data and Domain are classlib, and Web is the mvc project.
# 确保当前目录与 Template.sln 处于相同的目录
dotnet new classlib --name Data
dotnet new classlib --name Domain
dotnet new mvc --name Web
Add three items to the solution:
dotnet sln add Data
dotnet sln add Domain
dotnet sln add Web
Because the model layer is stored in Data, other projects need to have a reference to it:
cd Domain
dotnet add reference ../Data
cd ../Web
dotnet add reference ../Data
Of course, in actual development, we should also have a Service layer, which is used to store business code and reduce unnecessary business code in the controller. Then continue:
# 回到项目的根目录
cd ..
dotnet new classlib --name Service
dotnet sln add Service
Then add a reference to Service:
cd Service
dotnet add reference ../Data
Add a reference to the Service to the Web:
cd ../Web
dotnet add reference ../Service
Nowadays, a large-scale project is basically interface-oriented programming, and several key layers should be interface layers. In fact, we still lack the realization layer of Domain and the realization layer of Service.
cd ..
dotnet new classlib --name Domain.Implements
dotnet new classlib --name Service.Implements
In the corresponding implementation layer, introduce the interface layer they implement, and introduce Data:
cd Domain.Implements
dotnet add reference ../Data
dotnet add reference ../Domain
cd ../Service.Implements
dotnet add reference ../Data
dotnet add reference ../Domain
dotnet add reference ../Service
Here, the reference to the Domain interface layer is added to the implementation layer of the Service, instead of the reference to the implementation layer. This is because in interface-oriented programming, we need to hide the implementation of the Domain from the Service implementation layer, so for the Service implementation layer, there is no need to care about the implementation logic of the Domain layer.
Add references to the two newly created implementation layers in the Web:
cd ../Web
dotnet add reference ../Domain.Implements
dotnet add reference ../Service.Implements
Add these two implementation layers to the solution:
cd ..
dotnet sln add Domain.Implements
dotnet sln add Service.Implements
The following figure is the project structure chart so far:
On the whole, Data is the basis for data circulation between various layers, so each project depends on this project, the implementation layer of each interface layer is only visible to the Web, and the specific implementation of the other layers is actually not clear.
What are the benefits of hiding the implementation layer?
The caller does not know the logic of the implementer to avoid the caller’s dependence on a specific implementation
Conducive to teamwork, some teams are for module division, and some are for hierarchical division. No matter which kind, it is a good choice to use interfaces
Conducive to later optimization, you can easily switch the implementation layer without recompiling too much code
Of course, there are not only these benefits, but there is a downside. It will be more cumbersome when calling the service layer on the web layer, but this is not insoluble. The follow-up content will introduce how to solve this trouble.
2. Project supplement
Under normal circumstances, a complete project will also have a tool project and a test project. So, continue to add the following items:
dotnet new classlib --name Utils
Utils stands for tool classes. Usually there are more tool classes in a project, so they are drawn into one project and listed separately.
Add test items:
dotnet new nunit --name Test
The nunit 3 test framework is used here, and of course there is another xunit test framework.
Add two items to the solution:
dotnet sln add Utils
dotnet sln add Test
3. Summary
The content of this chapter aims to let everyone understand the hierarchical planning ideas of the actual development projects through the creation of projects. This does not mean that my is the best, but this is a relatively convenient hierarchical relationship that I have summarized. It is not explained here how to create such a project through Visual Studio or Rider, I hope everyone can try it by themselves.