SpringBoot入门
1.SpringBoot 是什么 SpringBoot 是一种整合了Spring,SpringMVC Mybaties等框架的框架使用SpringBoot可以简化开发,提高开发效率.
2.SpringBoot快速入门
1.建立一个新的springBoot项目或者模块
Server URL 建议 改成阿里云的 构建模块速度 会快一些
添加web依赖
这样就是创建成功了
2.接下来就入门案例了 入门案例之前先说下@SpringBootApplication 这个 是SpringBoot的启动类 启动的入口在这。
2.1 使用postman 测试接口数据
2.2 定义请求处理类
开始测试
到这里就入门了.
那么由于前端 传递参数不同 后端处理方式也不一样 这里稍微总结一下各种后端处理前端参数的各种方式
1.简单参数
这里解释下@RestController 和@RequestMapping 两个注解的作用 @RestController 是 一种 rest 风格 的Controller 本质上就是一个控制器 被底层的dispatcherServlet
所指定处理前端来的数据任务根据 各种路径 @RequestMapping 是一种 映射路径前面的分号不要省略代表着
你的ip地址加端口号(ps说错了勿喷)
2.3 当前端参数与后端参数类型名称不一致时 可以用 @RequestParam 一一对应一下
测试
![在这里插入图片描述](https://img-blog.csdnimg.cn/b1fa8e24b0eb45028d751905c25bfad6.p
可以看到我们前端传递名字这个参数 是UserName 后端接收的确是name
那么这时候我们可以用@RequestParmam 来制定类型名称一致
测试
3.实体类对象
测试
成功 上面address不用管
4.复杂实体参数
定义实体类
后端
测试
5 数组参数
测试
6集合
这个要稍微注意下 要用桑@ReuestParam 注解来标记 要不会没有值
测试
7.日期
需要用上@DateTimeFormat注解
测试
8.json 开发主要数据传输用到最多
需要@RequestBody注解 将Use 类转换为json对象
测试
json 格式需要注意一下
8.路径参数
测试
二.响应
数据有接收 就有响应 在springBoot 中响应是怎么样的呢?
这就要用到一个注解@responseBoby 了 这个注解就是专门来响应 数组 集合数据的
@ResponseBody
● 名称:@ResponseBody
● 类型:方法注解、类注解
● 位置:SpringMVC控制器方法上/类上
● 作用:将当前方法返回值直接返回,如果是 实体/集合 转换为JSON返回
而在上面的案例中我们并没有用到这个注解这是为啥我们也能返回相应的数据类型呢?
而我们的案例中,并没有直接使用 @ResponseBody,原因是因为我们使用的是 @RestController注解,该注解中已经封装了@ResponseBody注解,已经包含了@ResponseBody注解的作用,我们无需要额外添加。
统一响应结果:
在上面我们看到我们返回的数据类型各种各样 没有任何规范 这在开发中是混乱的 如果开发的是大型项目 那么就会 发现 数据难以维护 所以在正常开发中我们都会定义统一的 规范来进行开发
定义返回类型
这样的情况下我们只要将返结果都是Result就行了
比如像这样 由于实体类Result 中的数据属性是Object类型的 所以我们可以返回任何类型的数据给前端
三.三层架构
那这里呢,我们首先需要了解软件开发领导涉及到的两个概念:内聚和耦合。
1).内聚:软件中各个功能模块内部的功能联系。
2).耦合:衡量软件中各个层/模块之间的依赖、关联的程度。
3).软件设计原则:高内聚低耦合。
高内聚、低耦合的目的是使程序模块的可重用性、移植性大大增强。
简单点说就是 不要在别的模块或者类中写 不是本类的代码 这样会加强两个类
或者模块之间的耦合性 动了一边 另外一边也要动。不利于代码的可重用性 。
让我们来看个案例
上面的代码就是 没有用三层架构写的方式完成的一个功能 从 里面来讨论
在正常开发中会出现 一个功能全部写在一起 没有分层 不方便维护 这还是少一点 如果代码业务逻辑复杂的情况下 过几天你就都不认识自己写的代码了
有设计层面的角度来说 我们将 上面的功能拆分为3部分 在 开发中这三层分别是
控制层: cotorller 请求处理 响应数据
业务层: Service 逻辑业务处理
数据访问层 dao 负责对数据库进行增删改查
将代码拆分为三层之后的代码
控制层:
业务层:
数据访问层
层是分了 但是解耦还没有解耦 解耦的思路都是用到接口
部分解耦
从上面我们可以看到 两个类之间存在着耦合的 情况 业务层对象在控制层中
当我们修改一方面的代码的 时候 两边都要修改 不利于维护 有没有办法可以让我解耦合呢? 有接口。
业务层
dao成接口
我们可以在接口中定义好功能 在其实现类实现 这样的话 我们就可以做到 实现多套方案了 但是这样就是部分解耦 有没有更好的 方式呢?
有
在上面的案例中我们发现 程序中的 耦合主要来自new 对象 只要new对象 了
一般类与类之间就耦合了 为了解耦 我们可以使用接口 多态来 部分解耦
但是 还不能完全解耦 sping 为我们 提供了 一个牛皮的 思路以及功能 就是
ioc 简称控制反转 既然创建对象会让类与类之间产生耦合 那么创建对象就交个Spring 这个容器来创建 由spring 容器来统一管理 那么类与类之间的耦合就没有了
说到ioc 就不得不提到DI DI的意思就是依赖注入容器创建好了对象 我们哪里要用到这个对象的 时候 我们就注入就行了 注入使用 @Autowired 来表示
代码改造:
dao层
使用了@Repository 将创建对象的任务交给 spring容器来管理
业务层:
使用@Component 来将创建对象的任务交给 spring容器管理
使用@Autowired 来注入对象 代表这里需要用到这个对象 这里虽然用到了这个对象 但是又和dao 层解耦了 我们以后修改代码不会去dao层去修改里面的逻辑了 更利于维护 重用
控制层
说下 控制反转常用的四个注解
最后的细节 关于注入的
注入也有三个方式:
由于我们在正常的业务需求中有可能会用到多套方案 所以说一个接口下面会有几个实现类 这时候我们依赖注入就不行了 spring容器并正确的确定你要哪个对象
所以提供了三种方案
方式一:
方式二
常用 注意:名字是类名开头的小写 并不是大写 大写的话 在容器中会找不到这个对象。
方式三:
完结撒花。
The end