The SpringBoot framework inherits the basic functions of Spring, but has some differences in the project hierarchy. This article focuses on sorting out the basic hierarchical structure of the backend in the SpringBoot project.
It is recommended to study the Java Development Manual (Songshan Edition) for the specific development specifications of the project. This article will not go into details one by one.
Controller layer:
This layer defines the interface and calls the service layer interface method to complete the business logic.
Function:
Accept the front-end request, call the service, accept the data returned by the service, and then respond to the client.
Service layer:
The service layer is a business service, calling the mapper layer and providing it to the controller layer for use, and indirectly dealing with the database.
The project structure consists of two parts, the interface file and the interface implementation class file. The interface file defines the service layer methods called in the controller layer; the interface implementation class file completes the implementation of the methods defined in the service layer interface.
Note: The implementation of methods in the interface implementation class here refers to the implementation of business logic. Some methods may not be truly implemented in the implementation class, and their true implementation needs to be completed in the mapper layer file (mainly and database interaction).
Mapper layer:
The mapper layer is the layer that operates the database.
The mapper layer is divided into two parts, the mapper interface layer and the mapper.xml layer.
mapper interface layer:
Methods defined in the service interface are not truly implemented and require writing SQL statements to complete their functions.
mapper.xml layer:
(1) Configure general query mapping results:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd"> <mapper namespace="com.nayun.cultourism.mapper.CultureTourismSituationMapper"> <!-- 通用查询映射结果--> <resultMap id="cultureTourismResultMap" type="com.nayun.cultourism.entity.CultureTourismSituation"> <result column="id" property="id"/> <result column="name" property="name"/> <result column="annual_flow" property="annualFlow"/> <result column="position" property="position"/> <result column="illustration" property="illustration"/> <result column="pic_url" property="picUrl"/> <result column="creat_user" property="createUser"/> <result column="creat_dept" property="creatDept"/> <result column="creat_time" property="creatTime"/> <result column="update_user" property="updateUser"/> <result column="update_time" property="updateTime"/> <result column="status" property="status"/> <result column="is_deleted" property="isDeleted"/> <result column="address" property="address"/> </resultMap>
Notice:
-
The type of namespace and resultMap should point to the correct address, namespace points to the mapper file, and type points to the entity class.
-
column is a table field in the database, and property is the attribute name in the entity class (one-to-one correspondence).
Regarding column and property naming:
- Column is the database table field name, lowercase, and each word is separated by an underscore.
- Property is the name of the attribute in the entity class, and the naming generally conforms to camel case.
(2) Complete the SQL statement implementation of the method in the mapper interface:
In this module, specific SQL statements are written, and the query results are mapped to the resultMap in the method. The id is the method name defined in the mapper interface.
<!--查询所有景点数据-->
<select id="findAll" resultMap="cultureTourismResultMap">
select * from cockpit_tourist_spots where is_deleted = 0
</select>
<select id="getList" resultMap="cultureTourismResultMap">
select * from cockpit_tourist_spots where is_deleted = 0
<if test="cultureTourismSituation.name != null and cultureTourismSituation.name != ''">
and name LIKE CONCAT('%',#{cultureTourismSituation.name},'%')
</if>
</select>
Entity layer:
The so-called model , also called the pojo layer, is the database class in the project. This file contains the attributes of the entity class and the set and get methods of the corresponding attributes.
The attributes in the entity class correspond one-to-one with the database table fields. Generally, there is no need to write the corresponding set and get methods. The introduction of @Data annotation on the entity class will automatically inject the get, set and toString methods into the entity class, reducing the amount of code.
VO layer:
View objects are used in the presentation layer to encapsulate all the data of a specified page to facilitate the front-end to obtain data. The back-end integrates the data required by the front-end and packages it into a class.
scenes to be used:
If the front-end page needs to display specific data that can only be displayed after certain database operations, the data involved in the operation process is generally encapsulated in the vo layer to facilitate the front-end acquisition. And when defining the corresponding interface in the controller layer, the return type is specified as the vo class.
DTO layer:
The data object transmission layer is responsible for shielding the back-end entity layer and redefining and encapsulating the data required by the UI. Because the backend needs to store a large amount of data in actual business scenarios, and the data that users need is only part of it. In order to quickly obtain the data that users need, the data that users often use should be encapsulated in the dto layer. When calling the service layer, All logical operations only need to be called once.
Running process:
- The control layer receives the front-end request and calls the corresponding business layer interface method
- Business layer implementation class to implement the business layer interface
- Call the interface of the data layer within the method of the business layer implementation class
- The data layer implementation file (mapper.xml) implements the data layer interface
- Then the processing results are returned layer by layer
Generally speaking, the classification of what each layer does is just to make the business logic clearer and write code more convenient, so sometimes it needs to be based on the specific situation, but generally it is handled this way, because it actually provides a Rules allow you to put the same type of code together, thus forming a hierarchy, thereby achieving the purpose of hierarchical decoupling, reuse, and easy testing and maintenance.