githubEdit

day10-SpringBootWeb案例-1

SpringBootWeb 案例

前面我们已经讲解了 Web 前端开发的基础知识,也讲解了 Web 后端开发的基础(HTTP 协议、请求响应),并且也讲解了数据库 MySQL,以及通过 Mybatis 框架如何来完成数据库的基本操作。 那接下来,我们就通过一个案例,来将前端开发、后端开发、数据库整合起来。 而这个案例呢,就是我们前面提到的 Tlias 智能学习辅助系统。

在这个案例中,前端开发人员已经将前端工程开发完毕了。 我们需要做的,就是参考接口文档完成后端功能的开发,然后结合前端工程进行联调测试即可。

完成后的成品效果展示:

image-20220904103734643

今天的主要内容如下:

  • 准备工作

  • 部门管理

  • 员工管理

下面我们就进入到今天的第 1 个内容准备工作的学习。

1. 准备工作

准备工作的学习,我们先从"需求"和"环境搭建"开始入手。

1.1 需求&环境搭建

1.1.1 需求说明

1、部门管理

image-20221213205503102

部门管理功能开发包括:

  • 查询部门列表

  • 删除部门

  • 新增部门

  • 修改部门

2、员工管理

image-20221213205737307

员工管理功能开发包括:

  • 查询员工列表(分页、条件)

  • 删除员工

  • 新增员工

  • 修改员工

1.1.2 环境搭建

image-20221213230710821

步骤:

  1. 准备数据库表(dept、emp)

  2. 创建 springboot 工程,引入对应的起步依赖(web、mybatis、mysql 驱动、lombok)

  3. 配置文件 application.properties 中引入 mybatis 的配置信息,准备对应的实体类

  4. 准备对应的 Mapper、Service(接口、实现类)、Controller 基础结构

第 1 步:准备数据库表

第 2 步:创建一个 SpringBoot 工程,选择引入对应的起步依赖(web、mybatis、mysql 驱动、lombok) (版本选择 2.7.5 版本,可以创建完毕之后,在 pom.xml 文件中更改版本号)

image-20221213221142985
image-20221213221408420

生成的 pom.xml 文件:

创建项目工程目录结构:

image-20221213222039985

第 3 步:配置文件 application.properties 中引入 mybatis 的配置信息,准备对应的实体类

  • application.properties (直接把之前项目中的复制过来)

  • 实体类

第 4 步:准备对应的 Mapper、Service(接口、实现类)、Controller 基础结构

数据访问层:

  • DeptMapper

  • EmpMapper

业务层:

  • DeptService

  • DeptServiceImpl

  • EmpService

  • EmpServiceImpl

控制层:

  • DeptController

  • EmpController

项目工程结构:

image-20221213224927868

1.2 开发规范

了解完需求也完成了环境搭建了,我们下面开始学习开发的一些规范。

开发规范我们主要从以下几方面介绍:

1、开发规范-REST

我们的案例是基于当前最为主流的前后端分离模式进行开发。

image-20221213230911102

在前后端分离的开发模式中,前后端开发人员都需要根据提前定义好的接口文档,来进行前后端功能的开发。

后端开发人员:必须严格遵守提供的接口文档进行后端功能开发(保障开发的功能可以和前端对接)

image-20221213231519551

而在前后端进行交互的时候,我们需要基于当前主流的 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、开发流程

我们在进行功能开发时,都是根据如下流程进行:

image-20220904125004138
  1. 查看页面原型明确需求

    • 根据页面原型和需求,进行表结构设计、编写接口文档(已提供)

  2. 阅读接口文档

  3. 思路分析

  4. 功能接口开发

    • 就是开发后台的业务功能,一个业务功能,我们称为一个接口

  5. 功能接口测试

    • 功能开发完毕后,先通过 Postman 进行功能接口测试,测试通过后,再和前端进行联调测试

  6. 前后端联调测试

    • 和前端开发人员开发好的前端工程一起测试

2. 部门管理

我们按照前面学习的开发流程,开始完成功能开发。首先按照之前分析的需求,完成部门管理的功能开发。

开发的部门管理功能包含:

  1. 查询部门

  2. 删除部门

  3. 新增部门

  4. 更新部门(不讲解,自己独立完成)

2.1 查询部门

2.1.1 原型和需求

image-20221213234154699

查询的部门的信息:部门 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 思路分析

image-20221213235157345

2.1.4 功能开发

通过查看接口文档:部门列表查询

请求路径:/depts

请求方式:GET

请求参数:无

响应数据:json 格式

DeptController

@Slf4j 注解源码:

image-20221214000909044

DeptService(业务接口)

DeptServiceImpl(业务实现类)

DeptMapper

2.1.5 功能测试

功能开发完成后,我们就可以启动项目,然后打开 postman,发起 GET 请求,访问 :http://localhost:8080/depts

2.2 前后端联调

完成了查询部门的功能,我们也通过 postman 工具测试通过了,下面我们再基于前后端分离的方式进行接口联调。具体操作如下:

1、将资料中提供的"前端环境"文件夹中的压缩包,拷贝到一个没有中文不带空格的目录下

image-20221214100230484

2、拷贝到一个没有中文不带空格的目录后,进行解压(解压到当前目录)

image-20221214100039074

3、启动 nginx

image-20221214100703404
image-20221214101711107

4、打开浏览器,访问:http://localhost:90

image-20221214100918557

5、测试:部门管理 - 查询部门列表

image-20221214101436198

说明:只要按照接口文档开发功能接口,就能保证前后端程序交互

  • 后端:严格遵守接口文档进行功能接口开发

  • 前端:严格遵守接口文档访问功能接口

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 思路分析

image-20221214102705490

接口文档规定:

  • 前端请求路径:/depts/{id}

  • 前端请求方式:DELETE

问题 1:怎么在 controller 中接收请求路径中的路径参数?

问题 2:如何限定请求方式是 delete?

2.3.4 功能开发

通过查看接口文档:删除部门

请求路径:/depts/{id}

请求方式:DELETE

请求参数:路径参数 {id}

响应数据:json 格式

DeptController

DeptService

DeptServiceImpl

DeptMapper

2.3.5 功能测试

删除功能开发完成后,重新启动项目,使用 postman,发起 DELETE 请求:

image-20221214112451600

2.3.6 前后端联调

打开浏览器,测试后端功能接口:

image-20221214113708369
image-20221214113941657

2.4 新增部门

我们前面已完成了查询部门删除部门两个功能,也熟悉了开发的流程。下面我们继续完成新增部门功能。

2.4.1 需求

点击 "新增部门" 按钮,弹出新增部门对话框,输入部门名称,点击 "保存" ,将部门信息保存到数据库。

2.4.2 接口文档

添加部门

  • 基本信息

  • 请求参数

    格式:application/json

    参数说明:

    参数名
    类型
    是否必须
    备注

    name

    string

    必须

    部门名称

    请求参数样例:

  • 响应数据

    参数格式:application/json

    参数说明:

    参数名
    类型
    是否必须
    备注

    code

    number

    必须

    响应码,1 代表成功,0 代表失败

    msg

    string

    非必须

    提示信息

    data

    object

    非必须

    返回的数据

    响应数据样例:

2.4.3 思路分析

image-20221214115519648

接口文档规定:

  • 前端请求路径:/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 请求:

image-20221214153758708

2.4.6 前后端联调

打开浏览器,测试后端功能接口:

image-20221215105446189
image-20221214154645746

2.4.7 请求路径

我们部门管理的查询删除新增功能全部完成了,接下来我们要对 controller 层的代码进行优化。

首先我们先来看下目前 controller 层代码:

image-20221215110553435

以上三个方法上的请求路径,存在一个共同点:都是以/depts作为开头。(重复了)

在 Spring 当中为了简化请求路径的定义,可以把公共的请求路径,直接抽取到类上,在类上加一个注解@RequestMapping,并指定请求路径"/depts"。代码参照如下:

image-20221215111110219

优化前后的对比:

image-20221215111309042

注意事项:一个完整的请求路径,应该是类上@RequestMapping 的 value 属性 + 方法上的 @RequestMapping 的 value 属性

3. 员工管理

完成了部门管理的功能开发之后,我们进入到下一环节员工管理功能的开发。

image-20221215142107329

基于以上原型,我们可以把员工管理功能分为:

  1. 分页查询(今天完成)

  2. 带条件的分页查询(今天完成)

  3. 删除员工(今天完成)

  4. 新增员工(后续完成)

  5. 修改员工(后续完成)

那下面我们就先从分页查询功能开始学习。

3.1 分页查询

3.1.1 基础分页

3.1.1.1 需求分析

我们之前做的查询功能,是将数据库中所有的数据查询出来并展示到页面上,试想如果数据库中的数据有很多(假设有十几万条)的时候,将数据全部展示出来肯定不现实,那如何解决这个问题呢?

使用分页解决这个问题。每次只展示一页的数据,比如:一页展示 10 条数据,如果还想看其他的数据,可以通过点击页码进行查询。

image-20221215141233541

要想从数据库中进行分页查询,我们要使用LIMIT关键字,格式为:limit 开始索引 每页显示的条数

查询第 1 页数据的 SQL 语句是:

查询第 2 页数据的 SQL 语句是:

查询第 3 页的数据的 SQL 语句是:

观察以上 SQL 语句,发现: 开始索引一直在改变 , 每页显示条数是固定的

开始索引的计算公式: 开始索引 = (当前页码 - 1) * 每页显示条数

我们继续基于页面原型,继续分析,得出以下结论:

  1. 前端在请求服务端时,传递的参数

    • 当前页码 page

    • 每页显示条数 pageSize

  2. 后端需要响应什么数据给前端

    • 所查询到的数据列表(存储到 List 集合中)

    • 总记录数

image-20221215152021068

后台给前端返回的数据包含: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 思路分析

image-20221215153413290

分页查询需要的数据,封装在 PageBean 对象中:

image-20221215154036047

3.1.1.4 功能开发

通过查看接口文档:员工列表查询

请求路径:/emps

请求方式:GET

请求参数:跟随在请求路径后的参数字符串。 例:/emps?page=1&pageSize=10

响应数据:json 格式

EmpController

@RequestParam(defaultValue="默认值") //设置请求参数默认值

EmpService

EmpServiceImpl

EmpMapper

3.1.1.5 功能测试

功能开发完成后,重新启动项目,使用 postman,发起 POST 请求:

image-20221215162008339

3.1.1.6 前后端联调

打开浏览器,测试后端功能接口:

image-20221215183413504

3.1.2 分页插件

3.1.2.1 介绍

前面我们已经完了基础的分页查询,大家会发现:分页查询功能编写起来比较繁琐。

image-20221215164811566

在 Mapper 接口中定义两个方法执行两条不同的 SQL 语句:

  1. 查询总记录数

  2. 指定页码的数据列表

在 Service 当中,调用 Mapper 接口的两个方法,分别获取:总记录数、查询结果列表,然后在将获取的数据结果封装到 PageBean 对象中。

大家思考下:在未来开发其他项目,只要涉及到分页查询功能(例:订单、用户、支付、商品),都必须按照以上操作完成功能开发

结论:原始方式的分页查询,存在着"步骤固定"、"代码频繁"的问题

解决方案:可以使用一些现成的分页插件完成。对于 Mybatis 来讲现在最主流的就是 PageHelper。

PageHelper 是 Mybatis 的一款功能强大、方便易用的分页插件,支持任何形式的单标、多表的分页查询。

官网:https://pagehelper.github.io/

image-20221215170038833

在执行 empMapper.list()方法时,就是执行:select * from emp 语句,怎么能够实现分页操作呢?

分页插件帮我们完成了以下操作:

  1. 先获取到要执行的 SQL 语句:select * from emp

  2. 把 SQL 语句中的字段列表,变为:count(*)

  3. 执行 SQL 语句:select count(*) from emp //获取到总记录数

  4. 再对要执行的 SQL 语句:select * from emp 进行改造,在末尾添加 limit ? , ?

  5. 执行改造后的 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

image-20221215162008339

后端程序 SQL 输出:

image-20221215174820377

3.2 分页查询(带条件)

完了分页查询后,下面我们需要在分页查询的基础上,添加条件。

3.2.1 需求

image-20221215175639974

通过员工管理的页面原型我们可以看到,员工列表页面的查询,不仅仅需要考虑分页,还需要考虑查询条件。 分页查询我们已经实现了,接下来,我们需要考虑在分页查询的基础上,再加上查询条件。

我们看到页面原型及需求中描述,搜索栏的搜索条件有三个,分别是:

  • 姓名:模糊匹配

  • 性别:精确匹配

  • 入职日期:范围匹配

而且上述的三个条件,都是可以传递,也可以不传递的,也就是动态的。 我们需要使用前面学习的 Mybatis 中的动态 SQL 。

3.2.2 思路分析

image-20221215180528415

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 请求:

image-20221215182344380

控制台 SQL 语句:

image-20221215182952789

3.2.5 前后端联调

打开浏览器,测试后端功能接口:

image-20221215183510458

3.3 删除员工

查询员完成之后,我们继续开发新的功能:删除员工。

3.3.1 需求

image-20221215183657413

当我们勾选列表前面的复选框,然后点击 "批量删除" 按钮,就可以将这一批次的员工信息删除掉了。也可以只勾选一个复选框,仅删除一个员工信息。

问题:我们需要开发两个功能接口吗?一个删除单个员工,一个删除多个员工

答案:不需要。 只需要开发一个功能接口即可(删除多个员工包含只删除一个员工)

3.3.2 接口文档

删除员工

  • 基本信息

  • 请求参数

    参数格式:路径参数

    参数说明:

参数名
类型
示例
是否必须
备注

ids

数组 array

1,2,3

必须

员工的 id 数组

请求参数样例:

  • 响应数据

    参数格式:application/json

    参数说明:

参数名
类型
是否必须
备注

code

number

必须

响应码,1 代表成功,0 代表失败

msg

string

非必须

提示信息

data

object

非必须

返回的数据

响应数据样例:

3.3.3 思路分析

image-20221215184714815

接口文档规定:

  • 前端请求路径:/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 请求:

image-20221215190229696

控制台 SQL 语句:

image-20221215190948723

3.3.6 前后端联调

打开浏览器,测试后端功能接口:

image-20221215190606676
image-20221215190640539

Last updated

Was this helpful?