Article directory
Presentation Layer Data Encapsulation
Data return format
What is the meaning of data encapsulation in the presentation layer? Let’s take a look at what problems exist in the format of the returned data based on the current addition, deletion, modification and query functions.
The return format of added, deleted and modified data is as follows:
true
The return format of querying a single piece of data is as follows:
{
"id": 1,
"type": "计算机理论",
"name": "Spring实战 第5版",
"description": "Spring入门经典教程"
}
The return format of querying all data is as follows:
[
{
"id": 1,
"type": "计算机理论",
"name": "Spring实战 第5版",
"description": "Spring入门经典教程"
},
{
"id": 2,
"type": "计算机理论",
"name": "Spring 5核心原理与30个类手写实战",
"description": "十年沉淀之作"
}
]
It can be found that the data returned by the current addition, deletion, and modification operations is a Boolean value, the query returns an object, and the query returns an array; then the front-end personnel need to use different data types when performing different operations.
Therefore, we need to integrate data and return a unified data format to the front-end personnel; so we unified a format for receiving data at the front-end: Create a result model class and encapsulate the data into the data attribute
The unified format of the added, deleted and modified data is as follows:
{
"data":true
}
After querying the unified format of a single data, it is as follows:
{
"data":{
"id": 1,
"type": "计算机理论",
"name": "Spring实战 第5版",
"description": "Spring入门经典教程"
}
}
After querying all data, the unified format is as follows:
{
"data":[
{
"id": 1,
"type": "计算机理论",
"name": "Spring实战 第5版",
"description": "Spring入门经典教程"
},
{
"id": 2,
"type": "计算机理论",
"name": "Spring 5核心原理与30个类手写实战",
"description": "十年沉淀之作"
}
]
}
But there is a new problem at present: the data returned by the operation of addition, deletion and modification is the same, so how to distinguish whether the operation is addition, deletion or modification after the front end gets the data?
For distinguishing data, we add a code attribute to the model class, and encapsulate the operation result into the code attribute
For example, the backend and the frontend agree on:
- 20011 represents new operation
- 20021 represents delete operation
- 20031 represents the modification operation
- If the attribute in data is true, the deletion is successful, and if it is false, the deletion fails
{
"code": 20011,
"data": false
}
{
"code": 20021,
"data": true
}
{
"code": 20031,
"data": true
}
The operation of our query also needs to agree with the front end to represent a number, such as 20041; the query single and all queries are 20041
{
"code": 20041,
"data":{
"id": 1,
"type": "计算机理论",
"name": "Spring实战 第5版",
"description": "Spring入门经典教程"
}
}
{
"code": 20041,
"data":[
{
"id": 1,
"type": "计算机理论",
"name": "Spring实战 第5版",
"description": "Spring入门经典教程"
},
{
"id": 2,
"type": "计算机理论",
"name": "Spring 5核心原理与30个类手写实战",
"description": "十年沉淀之作"
}
]
}
If the front end queries a piece of data that does not exist at this time, it must be the following return result, so does this 20041 represent success or failure?
At this time, the front-end personnel don't know it, and they need to take out the attributes in the data to know
{
"code": 20041,
"data":null
}
At this time, there is a new agreement. As long as the last digit is 0, it means that the query failed. We use 20040 to represent the query failure; the front end will not go to the data attribute to fetch data after knowing that the query fails
{
"code": 20040,
"data": null,
}
After the query fails, we need to encapsulate special messages into the message (msg) attribute, for example, return a text prompting that the query failed; here the final form of the model class is determined
At present, when the query result is 20041, the front-end personnel go to data to fetch data, and when the query result is 20040, display the prompt information in msg;
{
"code": 20040,
"data": null,
"msg": "数据查询失败，请重试！"
}
data encapsulation
We need to define a model class, such as Result, to return results of unified data
Model classes are generally defined under the controller package
public class Result {
private Object data;
private Integer code;
private String msg;
}
Note :
The fields in the Result class are not fixed and can be increased or decreased as needed
Several construction methods can also be provided for easy operation
public class Result {
private Object data;
private Integer code;
private String msg;
public Result() {
}
public Result(Integer code, Object data) {
this.data = data;
this.code = code;
}
public Result(Integer code, Object data, String msg) {
this.data = data;
this.code = code;
this.msg = msg;
}
public Object getData() {
return data;
}
public void setData(Object data) {
this.data = data;
}
public Integer getCode() {
return code;
}
public void setCode(Integer code) {
this.code = code;
}
public String getMsg() {
return msg;
}
public void setMsg(String msg) {
this.msg = msg;
}
}
Create a Code class under the controller package to set the unified data return result code
The constant design of the Code class is not fixed, and can be increased or decreased according to the needs, such as subdividing the query into SELECT_OK, SELECT_ALL_OK, SELECT_PAGE_OK
public class Code {
public static final Integer SAVE_OK = 20011;
public static final Integer DELETE_OK = 20021;
public static final Integer UPDATE_OK = 20031;
public static final Integer SELECT_OK = 20041;
public static final Integer SAVE_ERR = 20010;
public static final Integer DELETE_ERR = 20020;
public static final Integer UPDATE_ERR = 20030;
public static final Integer SELECT_ERR = 20040;
}
The controller method in BookController under the controller package needs to be changed, and the returned results should all return Result objects
@RestController
@RequestMapping("/books")
public class BookController {
@Autowired
private BookService bookService;
@PostMapping
public Result save(@RequestBody Book book) {
boolean flag = bookService.save(book);
return new Result(flag ? Code.SAVE_OK: Code.SAVE_ERR, flag);
}
@DeleteMapping("/{id}")
public Result delete(@PathVariable Integer id) {
boolean flag = bookService.delete(id);
return new Result(flag ? Code.DELETE_OK: Code.DELETE_ERR, flag);
}
@PutMapping
public Result update(@RequestBody Book book) {
boolean flag = bookService.update(book);
return new Result(flag ? Code.UPDATE_OK: Code.UPDATE_ERR, flag);
}
@GetMapping
public Result selectAll() {
List<Book> books = bookService.selectAll();
boolean flag = books != null;
Integer code = flag ? Code.SELECT_OK: Code.SELECT_ERR;
String mes = flag ? "": "数据查询失败, 请重试!";
return new Result(code, books, mes) ;
}
@GetMapping("/{id}")
public Result selectById(@PathVariable Integer id) {
Book book = bookService.selectById(id);
boolean flag = book != null;
Integer code = flag ? Code.SELECT_OK: Code.SELECT_ERR;
String msg = flag ? "": "数据查询失败, 请重试!";
return new Result(code, book, msg);
}
}
At this point, the data obtained by the front end sending a request to the back end is in a unified format
{
"data": {
"id": 2,
"type": "测试修改",
"name": "测试修改",
"description": "测试修改"
},
"code": 20041,
"msg": ""
}