type
status
date
slug
summary
tags
category
icon
password
SpringBootWeb案例
前面我们已经讲解了Web前端开发的基础知识,也讲解了Web后端开发的基础(HTTP协议、请求响应),并且也讲解了数据库MySQL,以及通过Mybatis框架如何来完成数据库的基本操作。 那接下来,我们就通过一个案例,来将前端开发、后端开发、数据库整合起来。 而这个案例呢,就是我们前面提到的Tlias智能学习辅助系统。
在这个案例中,前端开发人员已经将前端工程开发完毕了。 我们需要做的,就是参考接口文档完成后端功能的开发,然后结合前端工程进行联调测试即可。
完成后的成品效果展示:
今天的主要内容如下:
- 准备工作
- 部门管理
- 员工管理
下面我们就进入到今天的第1个内容
准备工作
的学习。1. 准备工作
准备工作的学习,我们先从"需求"和"环境搭建"开始入手。
1.1 需求&环境搭建
1.1.1 需求说明
1、部门管理
部门管理功能开发包括:
- 查询部门列表
- 删除部门
- 新增部门
- 修改部门
2、员工管理
员工管理功能开发包括:
- 查询员工列表(分页、条件)
- 删除员工
- 新增员工
- 修改员工
1.1.2 环境搭建
步骤:
- 准备数据库表(dept、emp)
- 创建springboot工程,引入对应的起步依赖(web、mybatis、mysql驱动、lombok)
- 配置文件application.properties中引入mybatis的配置信息,准备对应的实体类
- 准备对应的Mapper、Service(接口、实现类)、Controller基础结构
第1步:准备数据库表
第2步:创建一个SpringBoot工程,选择引入对应的起步依赖(web、mybatis、mysql驱动、lombok) (版本选择2.7.5版本,可以创建完毕之后,在pom.xml文件中更改版本号)
生成的pom.xml文件:
创建项目工程目录结构:
第3步:配置文件application.properties中引入mybatis的配置信息,准备对应的实体类
- application.properties (直接把之前项目中的复制过来)
- 实体类
第4步:准备对应的Mapper、Service(接口、实现类)、Controller基础结构
数据访问层:
- DeptMapper
- EmpMapper
业务层:
- DeptService
- DeptServiceImpl
- EmpService
- EmpServiceImpl
控制层:
- DeptController
- EmpController
项目工程结构:
1.2 开发规范
了解完需求也完成了环境搭建了,我们下面开始学习开发的一些规范。
开发规范我们主要从以下几方面介绍:
1、开发规范-REST
我们的案例是基于当前最为主流的前后端分离模式进行开发。
在前后端分离的开发模式中,前后端开发人员都需要根据提前定义好的接口文档,来进行前后端功能的开发。
后端开发人员:必须严格遵守提供的接口文档进行后端功能开发(保障开发的功能可以和前端对接)
而在前后端进行交互的时候,我们需要基于当前主流的REST风格的API接口进行交互。
什么是REST风格呢?
- REST(Representational State Transfer),表述性状态转换,它是一种软件架构风格。
传统URL风格如下:
我们看到,原始的传统URL呢,定义比较复杂,而且将资源的访问行为对外暴露出来了。
基于REST风格URL如下:
其中总结起来,就一句话:通过URL定位要操作的资源,通过HTTP动词(请求方式)来描述具体的操作。
在REST风格的URL中,通过四种请求方式,来操作数据的增删改查。
- GET : 查询
- POST :新增
- PUT :修改
- DELETE :删除
我们看到如果是基于REST风格,定义URL,URL将会更加简洁、更加规范、更加优雅。
注意事项:
- REST是风格,是约定方式,约定不是规定,可以打破
- 描述模块的功能通常使用复数,也就是加s的格式来描述,表示此类资源,而非单个资源。如:users、emps、books…
2、开发规范-统一响应结果
前后端工程在进行交互时,使用统一响应结果 Result。
3、开发流程
我们在进行功能开发时,都是根据如下流程进行:
- 查看页面原型明确需求
- 根据页面原型和需求,进行表结构设计、编写接口文档(已提供)
- 阅读接口文档
- 思路分析
- 功能接口开发
- 就是开发后台的业务功能,一个业务功能,我们称为一个接口
- 功能接口测试
- 功能开发完毕后,先通过Postman进行功能接口测试,测试通过后,再和前端进行联调测试
- 前后端联调测试
- 和前端开发人员开发好的前端工程一起测试
2. 部门管理
我们按照前面学习的开发流程,开始完成功能开发。首先按照之前分析的需求,完成
部门管理
的功能开发。开发的部门管理功能包含:
- 查询部门
- 删除部门
- 新增部门
- 更新部门(不讲解,自己独立完成)
2.1 查询部门
2.1.1 原型和需求
查询的部门的信息:部门ID、部门名称、修改时间通过页面原型以及需求描述,我们可以看到,部门查询,是不需要考虑分页操作的。
2.1.2 接口文档
部门列表查询
- 基本信息
- 请求参数
无
- 响应数据
参数格式:application/json
参数说明:
参数名 | 类型 | 是否必须 | 备注 |
code | number | 必须 | 响应码,1 代表成功,0 代表失败 |
msg | string | 非必须 | 提示信息 |
data | object[ ] | 非必须 | 返回的数据 |
|- id | number | 非必须 | id |
|- name | string | 非必须 | 部门名称 |
|- createTime | string | 非必须 | 创建时间 |
|- updateTime | string | 非必须 | 修改时间 |
响应数据样例:
2.1.3 思路分析
2.1.4 功能开发
通过查看接口文档:部门列表查询
请求路径:/depts请求方式:GET请求参数:无响应数据:json格式
DeptController
@Slf4j注解源码:
DeptService(业务接口)
DeptServiceImpl(业务实现类)
DeptMapper
2.1.5 功能测试
功能开发完成后,我们就可以启动项目,然后打开postman,发起GET请求,访问 :http://localhost:8080/depts
2.2 前后端联调
完成了查询部门的功能,我们也通过postman工具测试通过了,下面我们再基于前后端分离的方式进行接口联调。具体操作如下:
1、将资料中提供的"前端环境"文件夹中的压缩包,拷贝到一个没有中文不带空格的目录下
2、拷贝到一个没有中文不带空格的目录后,进行解压(解压到当前目录)
3、启动nginx
4、打开浏览器,访问:http://localhost:90
5、测试:部门管理 - 查询部门列表
说明:只要按照接口文档开发功能接口,就能保证前后端程序交互
- 后端:严格遵守接口文档进行功能接口开发
- 前端:严格遵守接口文档访问功能接口
2.3 删除部门
查询部门的功能我们搞定了,下面我们开始完成
删除部门
的功能开发。2.3.1 需求
点击部门列表后面操作栏的 "删除" 按钮,就可以删除该部门信息。 此时,前端只需要给服务端传递一个ID参数就可以了。 我们从接口文档中也可以看得出来。
2.3.2 接口文档
删除部门
- 基本信息
- 请求参数 参数格式:路径参数
参数说明:
参数名 | 类型 | 是否必须 | 备注 |
id | number | 必须 | 部门ID |
请求参数样例:
- 响应数据 参数格式:application/json
参数说明:
参数名 | 类型 | 是否必须 | 备注 |
code | number | 必须 | 响应码,1 代表成功,0 代表失败 |
msg | string | 非必须 | 提示信息 |
data | object | 非必须 | 返回的数据 |
响应数据样例:
2.3.3 思路分析
接口文档规定:
- 前端请求路径:/depts/{id}
- 前端请求方式:DELETE
问题1:怎么在controller中接收请求路径中的路径参数?问题2:如何限定请求方式是delete?
2.3.4 功能开发
通过查看接口文档:删除部门
请求路径:/depts/{id}请求方式:DELETE请求参数:路径参数 {id}响应数据:json格式
DeptController
DeptService
DeptServiceImpl
DeptMapper
2.3.5 功能测试
删除功能开发完成后,重新启动项目,使用postman,发起DELETE请求:
2.3.6 前后端联调
打开浏览器,测试后端功能接口:
2.4 新增部门
我们前面已完成了
查询部门
、删除部门
两个功能,也熟悉了开发的流程。下面我们继续完成新增部门
功能。2.4.1 需求
<img src="https://img.lvems.top/img/202311281925545.webp" style="zoom:80%;" />
点击 "新增部门" 按钮,弹出新增部门对话框,输入部门名称,点击 "保存" ,将部门信息保存到数据库。
2.4.2 接口文档
添加部门
- 基本信息
- 请求参数
格式:application/json
参数说明:
参数名 | 类型 | 是否必须 | 备注 |
name | string | 必须 | 部门名称 |
请求参数样例:
- 响应数据
参数格式:application/json
参数说明:
参数名 | 类型 | 是否必须 | 备注 |
code | number | 必须 | 响应码,1 代表成功,0 代表失败 |
msg | string | 非必须 | 提示信息 |
data | object | 非必须 | 返回的数据 |
响应数据样例:
2.4.3 思路分析
接口文档规定:
- 前端请求路径:/depts
- 前端请求方式:POST
- 前端请求参数 (Json格式):{ "name": "教研部" }
问题1:如何限定请求方式是POST?问题2:怎么在controller中接收json格式的请求参数?
2.4.4 功能开发
通过查看接口文档:新增部门
请求路径:/depts请求方式:POST请求参数:json格式响应数据:json格式
DeptController
DeptService
DeptServiceImpl
DeptMapper
2.4.5 功能测试
新增功能开发完成后,重新启动项目,使用postman,发起POST请求:
2.4.6 前后端联调
打开浏览器,测试后端功能接口:
2.4.7 请求路径
我们部门管理的
查询
、删除
、新增
功能全部完成了,接下来我们要对controller层的代码进行优化。首先我们先来看下目前controller层代码:
以上三个方法上的请求路径,存在一个共同点:都是以/depts作为开头。(重复了)
在Spring当中为了简化请求路径的定义,可以把公共的请求路径,直接抽取到类上,在类上加一个注解@RequestMapping,并指定请求路径"/depts"。代码参照如下:
优化前后的对比:
注意事项:一个完整的请求路径,应该是类上@RequestMapping的value属性 + 方法上的 @RequestMapping的value属性
3. 员工管理
完成了部门管理的功能开发之后,我们进入到下一环节员工管理功能的开发。
基于以上原型,我们可以把员工管理功能分为:
- 分页查询(今天完成)
- 带条件的分页查询(今天完成)
- 删除员工(今天完成)
- 新增员工(后续完成)
- 修改员工(后续完成)
那下面我们就先从分页查询功能开始学习。
3.1 分页查询
3.1.1 基础分页
3.1.1.1 需求分析
我们之前做的查询功能,是将数据库中所有的数据查询出来并展示到页面上,试想如果数据库中的数据有很多(假设有十几万条)的时候,将数据全部展示出来肯定不现实,那如何解决这个问题呢?
使用分页解决这个问题。每次只展示一页的数据,比如:一页展示10条数据,如果还想看其他的数据,可以通过点击页码进行查询。
要想从数据库中进行分页查询,我们要使用
LIMIT
关键字,格式为:limit 开始索引 每页显示的条数查询第1页数据的SQL语句是:查询第2页数据的SQL语句是:查询第3页的数据的SQL语句是:观察以上SQL语句,发现: 开始索引一直在改变 , 每页显示条数是固定的开始索引的计算公式: 开始索引 = (当前页码 - 1) * 每页显示条数
我们继续基于页面原型,继续分析,得出以下结论:
- 前端在请求服务端时,传递的参数
- 当前页码 page
- 每页显示条数 pageSize
- 后端需要响应什么数据给前端
- 所查询到的数据列表(存储到List 集合中)
- 总记录数
后台给前端返回的数据包含:List集合(数据列表)、total(总记录数)而这两部分我们通常封装到PageBean对象中,并将该对象转换为json格式的数据响应回给浏览器。
3.1.1.2 接口文档
员工列表查询
- 基本信息
- 请求参数
参数格式:queryString
参数说明:
参数名称 | 是否必须 | 示例 | 备注 |
name | 否 | 张 | 姓名 |
gender | 否 | 1 | 性别 , 1 男 , 2 女 |
begin | 否 | 2010-01-01 | 范围匹配的开始时间(入职日期) |
end | 否 | 2020-01-01 | 范围匹配的结束时间(入职日期) |
page | 是 | 1 | 分页查询的页码,如果未指定,默认为1 |
pageSize | 是 | 10 | 分页查询的每页记录数,如果未指定,默认为10 |
请求数据样例:
- 响应数据
参数格式:application/json
参数说明:
名称 | 类型 | 是否必须 | 默认值 | 备注 | 其他信息 |
code | number | 必须 | ㅤ | 响应码, 1 成功 , 0 失败 | ㅤ |
msg | string | 非必须 | ㅤ | 提示信息 | ㅤ |
data | object | 必须 | ㅤ | 返回的数据 | ㅤ |
|- total | number | 必须 | ㅤ | 总记录数 | ㅤ |
|- rows | object [] | 必须 | ㅤ | 数据列表 | item 类型: object |
|- id | number | 非必须 | ㅤ | id | ㅤ |
|- username | string | 非必须 | ㅤ | 用户名 | ㅤ |
|- name | string | 非必须 | ㅤ | 姓名 | ㅤ |
|- password | string | 非必须 | ㅤ | 密码 | ㅤ |
|- entrydate | string | 非必须 | ㅤ | 入职日期 | ㅤ |
|- gender | number | 非必须 | ㅤ | 性别 , 1 男 ; 2 女 | ㅤ |
|- image | string | 非必须 | ㅤ | 图像 | ㅤ |
|- job | number | 非必须 | ㅤ | 职位, 说明: 1 班主任,2 讲师, 3 学工主管, 4 教研主管, 5 咨询师 | ㅤ |
|- deptId | number | 非必须 | ㅤ | 部门id | ㅤ |
|- createTime | string | 非必须 | ㅤ | 创建时间 | ㅤ |
|- updateTime | string | 非必须 | ㅤ | 更新时间 | ㅤ |
响应数据样例:
3.1.1.3 思路分析
分页查询需要的数据,封装在PageBean对象中:
3.1.1.4 功能开发
通过查看接口文档:员工列表查询
请求路径:/emps请求方式:GET请求参数:跟随在请求路径后的参数字符串。 例:/emps?page=1&pageSize=10响应数据:json格式
EmpController
@RequestParam(defaultValue="默认值") //设置请求参数默认值
EmpService
EmpServiceImpl
EmpMapper
3.1.1.5 功能测试
功能开发完成后,重新启动项目,使用postman,发起POST请求:
3.1.1.6 前后端联调
打开浏览器,测试后端功能接口:
3.1.2 分页插件
3.1.2.1 介绍
前面我们已经完了基础的分页查询,大家会发现:分页查询功能编写起来比较繁琐。
在Mapper接口中定义两个方法执行两条不同的SQL语句:
- 查询总记录数
- 指定页码的数据列表
在Service当中,调用Mapper接口的两个方法,分别获取:总记录数、查询结果列表,然后在将获取的数据结果封装到PageBean对象中。大家思考下:在未来开发其他项目,只要涉及到分页查询功能(例:订单、用户、支付、商品),都必须按照以上操作完成功能开发
结论:原始方式的分页查询,存在着"步骤固定"、"代码频繁"的问题
解决方案:可以使用一些现成的分页插件完成。对于Mybatis来讲现在最主流的就是PageHelper。
PageHelper是Mybatis的一款功能强大、方便易用的分页插件,支持任何形式的单标、多表的分页查询。
在执行empMapper.list()方法时,就是执行:select * from emp 语句,怎么能够实现分页操作呢?分页插件帮我们完成了以下操作:
- 先获取到要执行的SQL语句:select * from emp
- 把SQL语句中的字段列表,变为:count(*)
- 执行SQL语句:select count(*) from emp //获取到总记录数
- 再对要执行的SQL语句:select * from emp 进行改造,在末尾添加 limit ? , ?
- 执行改造后的SQL语句:select * from emp limit ? , ?
3.1.2.2 代码实现
当使用了PageHelper分页插件进行分页,就无需再Mapper中进行手动分页了。 在Mapper中我们只需要进行正常的列表查询即可。在Service层中,调用Mapper的方法之前设置分页参数,在调用Mapper方法执行查询之后,解析分页结果,并将结果封装到PageBean对象中返回。
1、在pom.xml引入依赖
2、EmpMapper
3、EmpServiceImpl
3.1.2.3 测试
功能开发完成后,我们重启项目工程,打开postman,发起GET请求,访问 :http://localhost:8080/emps?page=1&pageSize=5
后端程序SQL输出:
3.2 分页查询(带条件)
完了分页查询后,下面我们需要在分页查询的基础上,添加条件。
3.2.1 需求
通过员工管理的页面原型我们可以看到,员工列表页面的查询,不仅仅需要考虑分页,还需要考虑查询条件。 分页查询我们已经实现了,接下来,我们需要考虑在分页查询的基础上,再加上查询条件。
我们看到页面原型及需求中描述,搜索栏的搜索条件有三个,分别是:
- 姓名:模糊匹配
- 性别:精确匹配
- 入职日期:范围匹配
而且上述的三个条件,都是可以传递,也可以不传递的,也就是动态的。 我们需要使用前面学习的Mybatis中的动态SQL 。
3.2.2 思路分析
3.2.3 功能开发
通过查看接口文档:员工列表查询
请求路径:/emps请求方式:GET请求参数:
参数名称 是否必须 示例 备注 name 否 张 姓名 gender 否 1 性别 , 1 男 , 2 女 begin 否 2010-01-01 范围匹配的开始时间(入职日期) end 否 2020-01-01 范围匹配的结束时间(入职日期) page 是 1 分页查询的页码,如果未指定,默认为1 pageSize 是 10 分页查询的每页记录数,如果未指定,默认为10
在原有分页查询的代码基础上进行改造:
EmpController
EmpService
EmpServiceImpl
EmpMapper
EmpMapper.xml
3.2.4 功能测试
功能开发完成后,重启项目工程,打开postman,发起GET请求:
控制台SQL语句:
3.2.5 前后端联调
打开浏览器,测试后端功能接口:
3.3 删除员工
查询员完成之后,我们继续开发新的功能:删除员工。
3.3.1 需求
当我们勾选列表前面的复选框,然后点击 "批量删除" 按钮,就可以将这一批次的员工信息删除掉了。也可以只勾选一个复选框,仅删除一个员工信息。
问题:我们需要开发两个功能接口吗?一个删除单个员工,一个删除多个员工
答案:不需要。 只需要开发一个功能接口即可(删除多个员工包含只删除一个员工)
3.3.2 接口文档
删除员工
- 基本信息
- 请求参数
参数格式:路径参数
参数说明:
参数名 | 类型 | 示例 | 是否必须 | 备注 |
ids | 数组 array | 1,2,3 | 必须 | 员工的id数组 |
请求参数样例:
- 响应数据
参数格式:application/json
参数说明:
参数名 | 类型 | 是否必须 | 备注 |
code | number | 必须 | 响应码,1 代表成功,0 代表失败 |
msg | string | 非必须 | 提示信息 |
data | object | 非必须 | 返回的数据 |
响应数据样例:
3.3.3 思路分析
接口文档规定:
- 前端请求路径:/emps/{ids}
- 前端请求方式:DELETE
问题1:怎么在controller中接收请求路径中的路径参数?问题2:如何限定请求方式是delete?问题3:在Mapper接口中,执行delete操作的SQL语句时,条件中的id值是不确定的是动态的,怎么实现呢?
3.3.4 功能开发
通过查看接口文档:删除员工
请求路径:/emps/{ids}请求方式:DELETE请求参数:路径参数 {ids}响应数据:json格式
EmpController
EmpService
EmpServiceImpl
EmpMapper
EmpMapper.xml
3.3.5 功能测试
功能开发完成后,重启项目工程,打开postman,发起DELETE请求:
控制台SQL语句:
3.3.6 前后端联调
打开浏览器,测试后端功能接口:
- 作者:lveMonsi
- 链接:https://blog.lvems.top/article/231128
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议,转载请注明出处。