1、请求
方法形参名称与请求参数名称不匹配时,会出现请求格式不正确的错误
如果方法形参名称与请求参数名称不匹配,可以使用 @RequestParam 完成映射
请求参数名与形参对象属性名相同且请求参数为多个,定义数组类型形参即可接收参数
如果使用集合接收参数时,可以使用 @RequestParam 绑定参数关系,否则无法接受到请求参数
传入日期参数时,使用 @DateTimeFormat 注解完成日期参数格式转换
传入JSON数据时,键名与形参对象属性名相同,定义POJO类型形参即可接收参数;
在接收参数时需要使用 @RequestBody 标识形参
否则无法接收到传入参数
在使用路径传参时,通过请求URL直接传递参数,使用{…}来标识该路径参数
需要使用 @PathVariable 获取路径参数,否则路径变量就不会被使用
2、响应
在 @RestController 注解中已经包含了 @Controller 和 @ResponseBody
在响应中需要统一响应结果,比如Result风格的响应
3、分层解耦
3.1、三层架构
三层架构是一种常见的软件架构模式,用于将应用程序的功能划分为三个独立的层次,以实现松耦合、可维护和可扩展的系统设计。
这三个层次分别是:
请求处理层:该层负责与用户交互,处理用户输入和展示输出结果。它通常包括用户界面、Web页面、移动应用程序等。表现层主要关注用户体验和界面设计,将用户的请求传递给业务逻辑层,并将处理结果展示给用户。
业务逻辑层:该层包含应用程序的核心业务逻辑。它负责处理用户请求,进行业务处理和数据处理。业务逻辑层通常包括各种服务、业务逻辑的实现、数据验证和处理等。它独立于具体的表现层和数据访问层,确保业务逻辑的独立性和可重用性。
数据访问层:该层负责与数据存储系统(如数据库)进行交互,提供数据的读取、写入和更新等操作。数据访问层封装了对数据的具体访问细节,使得业务逻辑层不需要关注具体的数据存储细节。它提供了一种统一的接口,使得业务逻辑层可以方便地操作数据。
3.2、分层解耦
软件的设计原则是:高内聚低耦合
内聚:软件中各个功能模块内部的功能联系。
耦合:衡量软件中各个层/模块之间的依赖、关联的程度。
通过分层解耦,可以实现以下优势:
模块化和可维护性:每个层次都专注于特定的功能和职责,使得系统的各个模块可以独立开发、测试和维护。当需要修改或扩展某个功能时,只需关注特定层次,而无需对整个系统进行大规模的修改。
可扩展性:由于各个层次之间的低耦合性,当需要增加新的功能或模块时,可以通过添加新的层次或扩展现有的层次来实现,而不会对其他层次造成影响。这样可以实现系统的快速扩展和灵活性。
并行开发:各个层次之间的独立性使得不同团队或开发者可以并行开发不同层次的功能,提高开发效率和协作能力。
可测试性:分层解耦使得每个层次都可以独立地进行单元测试和集成测试,提高系统的可测试性和质量。
3.3、IOC(控制反转)&DI(依赖注入)
控制反转:对象的创建控制权由程序自身转移到外部(容器),这种思想称为控制反转。
依赖注入:容器为应用程序提供运行时,所依赖的资源,称之为依赖注入。
bean对象:IOC容器中创建、管理的对象,称之为bean对象。
Bean的声明
声明bean的时候,可以通过value属性指定bean的名字,如果没有指定,默认为类名首字母小写。
以上四个注解都可以声明bean,但在集成后端web开发之后,声明控制器bean只能用 @Controller。
声明bean的注解想要生效,需要被组件扫描注解 @ComponentScan 扫描。
在启动类的 @SpringBootApplication 注解中已经包含了 @ComponentScan 注解
依赖注入的方法:
setter 注入:通过set方法注入依赖的bean
构造器注入: 通过构造方法注入依赖的bean
注解注入: 通过@Autowired 或 @Resource注入依赖的bean
@Autowired 和 @Resource的区别
来源不同:@Autowired 来自 Spring 框架,而 @Resource 来自于(Java)JSR-250。
依赖查找顺序不同:@Autowired 先根据类型再根据名称查询,而 @Resource 先根据名称再根据类型查询。
支持的参数不同:@Autowired 只支持设置 1 个参数,而 @Resource 支持设置 7 个参数。
依赖注入用法不同:@Autowired 既支持构造方法注入,又支持属性注入和 Setter 注入,而 @Resource 只支持属性注入和 Setter 注入。
编译器 IDEA 的提示也不同:当注入 Mapper 对象时,使用 @Autowired 注解编译器会提示错误,而使用 @Resource 注解则不会提示错误