Building a project is inseparable from architecture. A good architecture can make development more effective. Technology is replaceable, and thinking is the same. So in the future technical career, you hear more of the core of a certain technology. What is the thinking and what problems have been dealt with. Above, encourage each other.
With more and more projects being developed, more and more realize the importance of project construction. Under normal circumstances, the background needs to provide: (mobile/web) interface services, management background interface services, and interface services between services , How to make each module reuse as much as possible to reduce duplication of code.
At this time, someone said: "I put all interface services in one project, so that no matter it is service, entity class, tool class, etc., it can be shared, isn't it all right?" At
this time, a question was extended: If one channel service is updated without affecting other channel services, will there be problems? Because you want to update, this service needs to be discontinued first. Once discontinued, this service is also referenced by other channels, it will be unavailable, and the project will become larger and larger, the framework will be staggered, and the maintenance cost will also increase. High, newcomers will make it difficult to get started.
How to build more appropriate?
There is no most suitable, only more suitable, this article is just a personal idea, if you have a better way, welcome to comment
Frame selection
- SpringBoot 2.3.5.RELEASE
- Mybatis-plus 3.4.1
- Knife4j 2.0.7
- Lombok
- Maven
Project structure
template-server-v2 #父项目
- template-core #数据库对应的entity，mapper，service，serviceImpl
- template-common #工具类
- template-service #业务处理
- template-controller #接口How are the project package responsibilities assigned
template-common
description
Mainly responsible for template-service tools, such as MD5, aes tools, some redis tools, etc., will be placed here
template-core
description
Mainly responsible for the mapping and addition, deletion, modification, and checking of database tables corresponding to entity classes. Note that there is no business processing, only generated classes.
mysql pom.xml which integrates and mybatis-plus and druid, using the code generation mybatis-plus plug can quickly generate entity class service, and a mapper, but also according to customize templates to generate different classes in different positions
template- The core is mainly for CRUD operations for all types of template-service.
advantage
- Use mybatis-plus to generate the plug-in, no need to install anything on the idea, can quickly generate entity classes and corresponding crud, minus the trouble of manual creation, you can modify the generation configuration, or customize the template
- The project package of template-service references template-core. If the database table fields are added or changed, you only need to modify the corresponding entities in template-core
template-service
description
Mainly responsible for the complete operation of the business. Generally, complex services are composed of CRUDs in several tables. Because template-core is referenced, the provided CRUD pairs are directly used to combine and splice them into services.
Transaction processing is also here, and there will be a Param interface parameter package and VO visual layer result package in the template-service: mainly for the reception of controller interface parameters and return of results
advantage
- The separation of template-service enables other controller project packages to be referenced and reduces the same code writing. For example: For example, we need to build a mall, which has a PC version + APP version + applet version. If the business is the same, only The controller and verification rules are different. At this time, the benefits of withdrawal
template-controller
description
Mainly responsible for interface supply, swagger document display, global exception handling, result set return, request log saving, interface permissions and other related interface processing operations. No business is processed here, and parameters are received and forwarded to the service.
If there is an app interface, a management backend interface, a pc interface, and an applet interface, then the template-controller will correspond to 4 projects, which can be template-controller- app, template-controller-applets, template-controller-back, template-controller-pc, the
same is: reference the required template-service function package; the difference is: interface verification, login method, interface documentation, log records, etc. . . .
advantage
- The separation of different channel interfaces allows them to not affect each other regardless of whether they are upgrading or discontinuing services, because they will have multiple controller project packages.
- Framework separation. For example, I used Spring Security before managing the backend. If I use it later, I will change to Shiro. I only need to modify the template-controller-back project package. It has nothing to do with others. Just collapse your own. Nothing wrong
- The maintenance is higher. Newcomers need to familiarize themselves with the management backend interface. They only need to pay attention to a single template-controller-back project package. Not all interfaces will be crowded together. Newcomers have a headache, and they are also obsessed with maintaining them.
- Scalability is better. If template-controller-app needs to do load, it will do a single engineering package service processing, and the others will not affect.
Project source code