After the previous articles, our data layer and business layer are basically set up,
and then we have to deal with the presentation layer.
For the development of the presentation layer, we still use the Restful mentioned before
and then use Postman to test our interface.
Let’s start without further ado.
Create a controller package in the same directory as the startup class.
Next, create a class called BookController
BookController. The reference code is as follows
package com.example.bookconfig.controller;
import com.example.bookconfig.domain.book;
import com.example.bookconfig.service.IBookService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import java.util.List;
@RestController
@RequestMapping("/books")
public class BookController {
@Autowired
private IBookService IBookService;
@GetMapping
public List<book> getAll() {
return IBookService.list();
}
}
Here we declare the RestController development model and then declare the public path as the
conditions of books, assemble the IBookService interface, which is the service logic layer interface we wrote above,
then define the getAll query method, declare the request method as get, and then call the list provided by MP to query all data Method
Then we start the project
because the port we started here is 80, which is the default port.
We directly open Postman
and visit http://localhost/books
to see that the output is very smooth
Then it's the porter's job.
Let's add an added function first.
@PostMapping
public boolean save(@RequestBody book book){
return IBookService.save(book);
}
Define a save function and declare it as a post type request and then return a Boolean type to notify whether the operation is successful.
RequestBody declares that this parameter is taken in the json of the body,
and then we remember that the request type is post through the Postman operation.
The address is the same because we did not set the address separately and then the following Match the parameters accordingly.
The parameter is the JSON format of the body format in raw, and then you don’t need to teach how to write JSON.
After the call, our return value will come out.
Then go to our database.
Our data will be added
and then modified directly with PutMapping The modification is a PUT type request, and the calling method is basically the same as adding. Calling the updateById function of MP,
we changed the piece of data just added to him.
@PutMapping
public boolean pudata(@RequestBody book book){
return IBookService.updateById(book);
}
Our Postman just changed the type to put and then added an id because he needs to change a certain item according to the id.
Other configurations are the same as adding. The running
results are as follows.
We also returned a true here.
Let’s check the data in the database
. The data has been modified.
Then we delete
The request type Delete adds a path parameter id
and then calls the removeById function of MP
@DeleteMapping("{id}")
public boolean delete(@PathVariable Integer id){
return IBookService.removeById(id);
}
Our Postman request type must be Delete and followed by the path id. Here we delete the one with id 11.
Run the following
to check that the data is successfully deleted
. Then we add a query by id
@GetMapping("{id}")
public book getById(@PathVariable Integer id){
return IBookService.getById(id);
}
Go to the test side and get the request path parameters.
The running results are as follows
, and then we will do pagination query
But we will find that you have to transfer an object of IPage,
which is quite unfriendly,
so let’s change
the abstract method of IBookService under service
IPage<book> getPage(int page,int pageSize);
Pass in two numeric variables, which are the current page and how many items are displayed on each page
The bookServiceI under the impl under the service package
implements this function.
The reference code is as follows
package com.example.webdom.service.impl;
import com.baomidou.mybatisplus.core.metadata.IPage;
import com.baomidou.mybatisplus.extension.plugins.pagination.Page;
import com.baomidou.mybatisplus.extension.service.impl.ServiceImpl;
import com.example.webdom.dao.bookDao;
import com.example.webdom.domain.book;
import com.example.webdom.service.IBookService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
@Service
public class bookServiceI extends ServiceImpl<bookDao, book> implements IBookService {
@Autowired
private bookDao bookDao;
@Override
public IPage<book> getPage(int page, int pageSize) {
IPage<book> pageDate = new Page(page,pageSize);
bookDao.selectPage(pageDate,null);
return pageDate;
}
}
Some people may say that the operation of transferring IPage should be placed in the controller, but what I want to say is that professional people do professional things.
Our logic should be written in the business layer as much as possible
, and then use this function in BookController
@GetMapping("/page")
public IPage<book> getPage(@RequestParam int page,int pageSize) {
System.out.println("BookController.getPage");
return IBookService.getPage(page, pageSize);
}
It should be noted here that we add page at the end because we are afraid that it will be repeated with the previous interface, because if we do not add this and check all the interfaces, it will definitely conflict with each other. We receive two parameters to query the page number and check how many items we check in
Postman
. The test code in the test is as follows. Here,
it should be noted that our method declares a page subpath separately, and then the form type under the type body below is a parameter declared by RequestParam, and then
add the parameters below to query the first page and display two
runs on each page. The result is as follows,
very perfect