目录
（2）面试题 ： @Autowird 与 @Resource的区别
前言
在上一次的SpringbootWeb基础中，我们开发了springbootweb的入门程序。 基于SpringBoot的方式开发一个web应用，浏览器发起请求 /hello 后 ，给浏览器返回字符串 “Hello World ~”。
其实呢，是我们在浏览器发起请求，请求了我们的后端web服务器(也就是内置的Tomcat)。而我们在开发web程序时呢，定义了一个控制器类Controller，请求会被部署在Tomcat中的Controller接收，然后Controller再给浏览器一个响应，响应一个字符串 “Hello World”。 而在请求响应的过程中是遵循HTTP协议的。
但是呢，这里要告诉大家的时，其实在Tomcat这类Web服务器中，是不识别我们自己定义的Controller的。但是我们前面讲到过Tomcat是一个Servlet容器，是支持Serlvet规范的，所以呢，在tomcat中是可以识别 Servlet程序的。 那我们所编写的XxxController 是如何处理请求的，又与Servlet之间有什么联系呢？
其实呢，在SpringBoot进行web程序开发时，它内置了一个核心的Servlet程序 DispatcherServlet，称之为 核心控制器。 DispatcherServlet 负责接收页面发送的请求，然后根据执行的规则，将请求再转发给后面的请求处理器Controller，请求处理器处理完请求之后，最终再由DispatcherServlet给浏览器响应数据。
那将来浏览器发送请求，会携带请求数据，包括：请求行、请求头；请求到达tomcat之后，tomcat会负责解析这些请求数据，然后呢将解析后的请求数据会传递给Servlet程序的HttpServletRequest对象，那也就意味着 HttpServletRequest 对象就可以获取到请求数据。 而Tomcat，还给Servlet程序传递了一个参数 HttpServletResponse，通过这个对象，我们就可以给浏览器设置响应数据 。
那上述所描述的这种浏览器/服务器的架构模式呢，我们称之为：BS架构。
这次内容主要就围绕着：请求、响应进行。主要包含三个部分：
请求
响应
分层解耦
一、请求（学会使用postman和接收请求参数）
1.后端接口测试工具Postman
（1）引入
之前我们课程中有提到当前最为主流的开发模式：前后端分离
在这种模式下，前端技术人员基于"接口文档"，开发前端程序；后端技术人员也基于"接口文档"，开发后端程序。
由于前后端分离，对我们后端技术人员来讲，在开发过程中，是没有前端页面的，那我们怎么测试自己所开发的程序呢？
方式1：像之前SpringBoot入门案例中一样，直接使用浏览器。在浏览器中输入地址，测试后端程序。
-
弊端：在浏览器地址栏中输入地址这种方式都是GET请求，如何我们要用到POST请求怎么办呢？
-
要解决POST请求，需要程序员自己编写前端代码（比较麻烦）
-
方式2：使用专业的接口测试工具（课程中我们使用Postman工具）
（2）介绍
-
Postman是一款功能强大的网页调试与发送网页HTTP请求的Chrome插件。
Postman原是Chrome浏览器的插件，可以模拟浏览器向后端服务器发起任何形式(如:get、post)的HTTP请求
使用Postman还可以在发起请求时，携带一些请求参数、请求头等信息
-
作用：常用于进行接口测试
-
特征
-
简单
-
实用
-
美观
-
大方
-
（3）安装和使用
双击资料中提供的
Postman-win64-8.3.1-Setup.exe即可自动安装。安装完成之后，进入页面中会提示有新版本可以升级（无需升级）
创建一个postman的账号 ，登录后创建工作空间
创建请求：
点击"Save"，保存当前请求
2.简单参数
（1）postman发送请求测试
get请求：
post请求：
（2）原始方式接收
在原始的Web程序当中，需要通过Servlet中提供的API：HttpServletRequest（请求对象），获取请求的相关信息。比如获取请求参数：
@RestController public class RequestController { //原始方式 @RequestMapping("/simpleParam") public String simpleParam(HttpServletRequest request){ // http://localhost:8080/simpleParam?name=Tom&age=10 // 请求参数： name=Tom&age=10 （有2个请求参数） // 第1个请求参数： name=Tom 参数名:name，参数值:Tom // 第2个请求参数： age=10 参数名:age , 参数值:10 String name = request.getParameter("name");//name就是请求参数名 String ageStr = request.getParameter("age");//age就是请求参数名 int age = Integer.parseInt(ageStr);//需要手动进行类型转换 System.out.println(name+" : "+age); return "OK"; } }
（3）SpringBoot方式
@RestController
public class RequestController {
// http://localhost:8080/simpleParam?name=Tom&age=10
// 第1个请求参数： name=Tom 参数名:name，参数值:Tom
// 第2个请求参数： age=10 参数名:age , 参数值:10
//springboot方式
@RequestMapping("/simpleParam")
public String simpleParam(String name , Integer age ){//形参名和请求参数名保持一致
System.out.println(name+" : "+age);
return "OK";
}
}（4）Spingboot方式参数名不一致问题
如果方法形参名称与请求参数名称不一致，controller方法中的形参还能接收到请求参数值吗？
下面把name换成username
@RestController public class RequestController { // http://localhost:8080/simpleParam?name=Tom&age=20 // 请求参数名：name //springboot方式 @RequestMapping("/simpleParam") public String simpleParam(String username , Integer age ){//请求参数名和形参名不相同 System.out.println(username+" : "+age); return "OK"; } }答案：运行没有报错。 controller方法中的username值为：null，age值为20
对于简单参数来讲，请求参数名和controller方法中的形参名不一致时，无法接收到请求数据
那么如果我们开发中，遇到了这种请求参数名和controller方法中的形参名不相同，怎么办？
解决方案：可以使用Spring提供的@RequestParam注解完成映射
在方法形参前面加上 @RequestParam 然后通过value属性执行请求参数名，从而完成映射。代码如下：
@RestController public class RequestController { // http://localhost:8080/simpleParam?name=Tom&age=20 // 请求参数名：name //springboot方式 @RequestMapping("/simpleParam") public String simpleParam(@RequestParam("name") String username , Integer age ){ System.out.println(username+" : "+age); return "OK"; } }
3.实体参数
在使用简单参数做为数据传递方式时，前端传递了多少个请求参数，后端controller方法中的形参就要书写多少个。如果请求参数比较多，通过上述的方式一个参数一个参数的接收，会比较繁琐。
此时，我们可以考虑将请求参数封装到一个实体类对象中。 要想完成数据封装，需要遵守如下规则：请求参数名与实体类的属性名相同
（1）简单实体
简单实体就是没有类的自定义类的嵌套，比如上面的User类。
发送的请求就和简单参数一样
（2）复杂实体
就是，自定义类的嵌套。如下User类嵌套Address类
public class User { private String name; private Integer age; private Address address; //地址对象 }public class Address { private String province; private String city; }注意：作为传输的实体，标准实现javabean
Controller方法： （没什么变化）
@RestController public class RequestController { //实体参数：复杂实体对象 @RequestMapping("/complexPojo") public String complexPojo(User user){ System.out.println(user); return "OK"; } }
4.数组集合参数
数组集合参数的使用场景：在HTML的表单中，有一个表单项是支持多选的(复选框)，可以提交选择的多个值。
多个值是怎么提交的呢？其实多个值也是一个一个的提交。
后端程序接收上述多个值的方式有两种：
数组
集合
（1）数组
数组参数：请求参数名与形参数组名称相同且请求参数为多个，定义数组类型形参即可接收参数
Postman测试：
在前端请求时，有两种传递形式：
方式一： xxxxxxxxxx?hobby=game&hobby=java
方式二：xxxxxxxxxxxxx?hobby=game,java
（2）集合
集合参数：请求参数名与形参集合对象名相同且请求参数为多个，@RequestParam 绑定参数关系
注意：默认情况下，请求中参数名相同的多个值，是封装到数组。如果要封装到集合，要使用@RequestParam绑定参数关系
Postman测试：和数组一样
5.日期参数
@DateTimeFormat注解的pattern属性中指定了哪种日期格式，前端的日期参数就必须按照指定的格式传递。
后端controller方法中，需要使用Date类型或LocalDateTime类型，来封装传递的参数。
6.JSON参数
在学习前端技术时，我们有讲到过JSON，而在前后端进行交互时，如果是比较复杂的参数，前后端通过会使用JSON格式的数据进行传输。 （JSON是开发中最常用的前后端数据交互方式）
我们学习JSON格式参数，主要从以下两个方面着手：
Postman在发送请求时，如何传递json格式的请求参数
在服务端的controller方法中，如何接收json格式的请求参数
Postman发送JSON格式数据：只能发post请求
服务端Controller方法接收JSON格式数据：
传递json格式的参数，在Controller中会使用实体类进行封装。
封装规则：JSON数据键名与形参对象属性名相同，定义POJO类型形参即可接收参数。需要使用 @RequestBody标识。
@RequestBody注解：将JSON数据映射到形参的实体类对象中（JSON中的key和实体类中的属性名保持一致）
7.路径参数
传统的开发中请求参数是放在请求体(POST请求)传递或跟在URL后面通过?key=value的形式传递(GET请求)。
在现在的开发中，经常还会直接在请求的URL中传递参数。例如：
http://localhost:8080/user/1
http://localhost:880/user/1/0
上述的这种传递请求参数的形式呢，我们称之为：路径参数。
学习路径参数呢，主要掌握在后端的controller方法中，如何接收路径参数。
路径参数：
前端：通过请求URL直接传递参数
后端：使用{…}来标识该路径参数，需要使用@PathVariable获取路径参数
多个路径参数
Controller方法：
@RestController public class RequestController { //路径参数 @RequestMapping("/path/{id}/{name}") public String pathParam2(@PathVariable Integer id, @PathVariable String name){ System.out.println(id+ " : " +name); return "OK"; } }
8.Controller接收请求参数用到的注解
@RestController：放在类上面，表面这个类是Controller类
@RequestMapping：指明请求路径的URL的映射
@RequestParam：声明单个请求参数传入的参数名
@DateTimeFormat：指明日期参数的格式
@RequestBody：表明是JSON参数
@PathVarible：表明是路径参数，必须配合@RequestMapping("/xxx/{id}/{name}/...")
二、响应
前面我们学习过HTTL协议的交互方式：请求响应模式（有请求就有响应）
那么Controller程序呢，除了接收请求外，还可以进行响应。
1.@ResponseBody
在我们前面所编写的controller方法中，都已经设置了响应数据。
return回去的就是响应体中的回应数据
问题1
controller方法中的return的结果，怎么就可以响应给浏览器呢？
答案：使用@ResponseBody注解（类上或方法上）
问题2
都没看到使用@ResponseBody注解呀？
答案：@RestController=@Controller+@ResponseBody
已经包含了@ResponseBody注解
@RestController源码：
@Target({ElementType.TYPE}) //元注解（修饰注解的注解） @Retention(RetentionPolicy.RUNTIME) //元注解 @Documented //元注解 @Controller @ResponseBody public @interface RestController { @AliasFor( annotation = Controller.class ) String value() default ""; }
结论：在类上添加@RestController就相当于添加了@ResponseBody注解。
类上有@RestController注解或@ResponseBody注解时：表示当前类下所有的方法返回值做为响应数据
方法的返回值，如果是一个POJO对象或集合时，会先转换为JSON格式，在响应给浏览器
测试响应数据：
@RestController public class ResponseController { //响应字符串 @RequestMapping("/hello") public String hello(){ System.out.println("Hello World ~"); return "Hello World ~"; } //响应实体对象 @RequestMapping("/getAddr") public Address getAddr(){ Address addr = new Address();//创建实体类对象 addr.setProvince("广东"); addr.setCity("深圳"); return addr; } //响应集合数据 @RequestMapping("/listAddr") public List<Address> listAddr(){ List<Address> list = new ArrayList<>();//集合对象 Address addr = new Address(); addr.setProvince("广东"); addr.setCity("深圳"); Address addr2 = new Address(); addr2.setProvince("陕西"); addr2.setCity("西安"); list.add(addr); list.add(addr2); return list; } }结果（响应体中的数据）：
简单字符串
对象JSON
集合JSON
2.统一响应结果
如果我们开发一个大型项目，项目中controller方法将成千上万，使用上述方式将造成整个项目难以维护。那在真实的项目开发中是什么样子的呢？
在真实的项目开发中，无论是哪种方法，我们都会定义一个统一的返回结果。方案如下：
定义在一个实体类Result来包含以上信息。代码如下：
public class Result { private Integer code;//响应码，1 代表成功; 0 代表失败 private String msg; //响应码 描述字符串 private Object data; //返回的数据 public Result() { } public Result(Integer code, String msg, Object data) { this.code = code; this.msg = msg; this.data = data; } public Integer getCode() { return code; } public void setCode(Integer code) { this.code = code; } public String getMsg() { return msg; } public void setMsg(String msg) { this.msg = msg; } public Object getData() { return data; } public void setData(Object data) { this.data = data; } //增删改 成功响应(不需要给前端返回数据) public static Result success(){ return new Result(1,"success",null); } //查询 成功响应(把查询结果做为返回数据响应给前端) public static Result success(Object data){ return new Result(1,"success",data); } //失败响应 public static Result error(String msg){ return new Result(0,msg,null); } }
改造Controller：
@RestController public class ResponseController { //响应统一格式的结果 @RequestMapping("/hello") public Result hello(){ System.out.println("Hello World ~"); //return new Result(1,"success","Hello World ~"); return Result.success("Hello World ~"); } //响应统一格式的结果 @RequestMapping("/getAddr") public Result getAddr(){ Address addr = new Address(); addr.setProvince("广东"); addr.setCity("深圳"); return Result.success(addr); } //响应统一格式的结果 @RequestMapping("/listAddr") public Result listAddr(){ List<Address> list = new ArrayList<>(); Address addr = new Address(); addr.setProvince("广东"); addr.setCity("深圳"); Address addr2 = new Address(); addr2.setProvince("陕西"); addr2.setCity("西安"); list.add(addr); list.add(addr2); return Result.success(list); } }
postman重新测试响应体中数据：
三、案例
1.需求
加载并解析xml文件中的数据，完成数据处理，并在页面展示
2.Controller代码
@RestController
public class EmpController {
@RequestMapping("/listEmp")
public Result list(){
//1. 加载并解析emp.xml
String file = this.getClass().getClassLoader().getResource("emp.xml").getFile();
//System.out.println(file);
List<Emp> empList = XmlParserUtils.parse(file, Emp.class);
//2. 对数据进行转换处理 - gender, job
empList.stream().forEach(emp -> {
//处理 gender 1: 男, 2: 女
String gender = emp.getGender();
if("1".equals(gender)){
emp.setGender("男");
}else if("2".equals(gender)){
emp.setGender("女");
}
//处理job - 1: 讲师, 2: 班主任 , 3: 就业指导
String job = emp.getJob();
if("1".equals(job)){
emp.setJob("讲师");
}else if("2".equals(job)){
emp.setJob("班主任");
}else if("3".equals(job)){
emp.setJob("就业指导");
}
});
//3. 响应数据
return Result.success(empList);
}
}3.问题分析
上述案例的功能，我们虽然已经实现，但是呢，我们会发现案例中：解析XML数据，获取数据的代码，处理数据的逻辑的代码，给页面响应的代码全部都堆积在一起了，全部都写在controller方法中了。
当前程序的这个业务逻辑还是比较简单的，如果业务逻辑再稍微复杂一点，我们会看到Controller方法的代码量就很大了。
当我们要修改操作数据部分的代码，需要改动Controller
当我们要完善逻辑处理部分的代码，需要改动Controller
当我们需要修改数据响应的代码，还是需要改动Controller
这样呢，就会造成我们整个工程代码的复用性比较差，而且代码难以维护。 那如何解决这个问题呢？其实在现在的开发中，有非常成熟的解决思路，那就是分层开发。
四、分层解耦
软件设计模式都遵循一个理念：高内聚低耦合。
高内聚：一个模块或一层的代码都几种处理一种逻辑。
低耦合：各个模块之间的关联性低。
上面的案例中，把获取数据，处理数据，响应数据，这三个逻辑都放在Controller层，聚合度非常低，需要分层。
1.三层架构
（1）概述
那其实我们上述案例的处理逻辑呢，从组成上看可以分为三个部分：
数据访问：负责业务数据的维护操作，包括增、删、改、查等操作。
逻辑处理：负责业务逻辑处理的代码。
请求处理、响应数据：负责，接收页面的请求，给页面响应数据。
那其实我们上述案例的处理逻辑呢，从组成上看可以分为三个部分：
数据访问：负责业务数据的维护操作，包括增、删、改、查等操作。
逻辑处理：负责业务逻辑处理的代码。
请求处理、响应数据：负责，接收页面的请求，给页面响应数据。
按照上述的三个组成部分，在我们项目开发中呢，可以将代码分为三层：
Controller：控制层。接收前端发送的请求，对请求进行处理，并响应数据。
Service：业务逻辑层。处理具体的业务逻辑。
Dao：数据访问层(Data Access Object)，也称为持久层。负责数据访问操作，包括数据的增、删、改、查。
基于三层架构的程序执行流程：
前端发起的请求，由Controller层接收（Controller响应数据给前端）
Controller层调用Service层来进行逻辑处理（Service层处理完后，把处理结果返回给Controller层）
Serivce层调用Dao层（逻辑处理过程中需要用到的一些数据要从Dao层获取）
Dao层操作文件中的数据（Dao拿到的数据会返回给Service层）
（2） 原案例代码拆分
我们使用三层架构思想，来改造下之前的程序：
控制层包名：xxxx.controller
业务逻辑层包名：xxxx.service
数据访问层包名：xxxx.dao
控制层：接收前端发送的请求，对请求进行处理（调用Service层方法），并响应数据
@RestController public class EmpController { //业务层对象 private EmpService empService = new EmpServiceA(); @RequestMapping("/listEmp") public Result list(){ //1. 调用service层, 获取数据 List<Emp> empList = empService.listEmp(); //3. 响应数据 return Result.success(empList); } }
业务逻辑层：处理具体的业务逻辑 （先调取Dao层方法获取数据）
业务接口
//业务逻辑接口（制定业务标准） public interface EmpService { //获取员工列表 public List<Emp> listEmp(); }业务实现类
//业务逻辑实现类（按照业务标准实现） public class EmpServiceA implements EmpService { //dao层对象 private EmpDao empDao = new EmpDaoA(); @Override public List<Emp> listEmp() { //1. 调用dao, 获取数据 List<Emp> empList = empDao.listEmp(); //2. 对数据进行转换处理 - gender, job empList.stream().forEach(emp -> { //处理 gender 1: 男, 2: 女 String gender = emp.getGender(); if("1".equals(gender)){ emp.setGender("男"); }else if("2".equals(gender)){ emp.setGender("女"); } //处理job - 1: 讲师, 2: 班主任 , 3: 就业指导 String job = emp.getJob(); if("1".equals(job)){ emp.setJob("讲师"); }else if("2".equals(job)){ emp.setJob("班主任"); }else if("3".equals(job)){ emp.setJob("就业指导"); } }); return empList; } }
数据访问层：负责数据的访问操作，包含数据的增、删、改、查
数据访问接口
//数据访问层接口（制定标准） public interface EmpDao { //获取员工列表数据 public List<Emp> listEmp(); }数据访问实现类
//数据访问实现类 public class EmpDaoA implements EmpDao { @Override public List<Emp> listEmp() { //1. 加载并解析emp.xml String file = this.getClass().getClassLoader().getResource("emp.xml").getFile(); System.out.println(file); List<Emp> empList = XmlParserUtils.parse(file, Emp.class); return empList; } }
2.分层解耦
（1）还有耦合问题
虽然已经实现高内聚了，但是这三层模块之间 存在不小的耦合度。
比如在Service层，在处理数据逻辑的时候，要获取数据调用Dao层的方法，这时候就要创建一个Dao层的实例对象，这会导致我后面修改Dao层的实现类名，Service层的这个实例声明的代码就要跟着修改，非常麻烦。Controller层也一样。
把业务类变为EmpServiceB时，需要修改controller层中的代码
（2）解耦思路
首先不能在EmpController中使用new对象。代码如下：
此时，就存在另一个问题了，不能new，就意味着没有业务层对象（程序运行就报错），怎么办呢？
我们的解决思路是：
提供一个容器，容器中存储一些对象(例：EmpService对象)
controller程序从容器中获取EmpService类型的对象
我们想要实现上述解耦操作，就涉及到Spring中的两个核心概念：
控制反转： Inversion Of Control，简称IOC。对象的创建控制权由程序自身转移到外部（容器），这种思想称为控制反转。
对象的创建权由程序员主动创建转移到容器(由容器创建、管理对象)。这个容器称为：IOC容器或Spring容器
就是使用@Component注解
依赖注入： Dependency Injection，简称DI。容器为应用程序提供运行时，所依赖的资源，称之为依赖注入。
程序运行时需要某个资源，此时容器就为其提供这个资源。
例：EmpController程序运行时需要EmpService对象，Spring容器就为其提供并注入EmpService对象
就是使用@Autowired注解
IOC容器中创建、管理的对象，称之为：bean对象
3. IOC&DI入门
拿分完三层架构的案例代码来解耦入门
任务：完成Controller层、Service层、Dao层的代码解耦
思路：
删除Controller层、Service层中new对象的代码
Service层及Dao层的实现类，交给IOC容器管理
为Controller及Service注入运行时依赖的对象
Controller程序中注入依赖的Service层对象
Service程序中注入依赖的Dao层对象
第1步：删除Controller层、Service层中new对象的代码
第2步：Service层及Dao层的实现类，交给IOC容器管理
使用Spring提供的注解：@Component ，就可以实现类交给IOC容器管理
第3步：为Controller及Service注入运行时依赖的对象
使用Spring提供的注解：@Autowired ，就可以实现程序运行时IOC容器自动注入需要的依赖对象
就是删除new对象的代码上面添加@Autowired
1.Controller程序中注入依赖的Service层对象
2.Service程序中注入依赖的Dao层对象
4.IOC详解
（1）bean声明
前面我们提到IOC控制反转，就是将对象的控制权交给Spring的IOC容器，由IOC容器创建及管理对象。IOC容器创建的对象称为bean对象。
在之前的入门案例中，要把某个对象交给IOC容器管理，需要在类上添加一个注解：@Component
而Spring框架为了更好的标识web应用程序开发当中，bean对象到底归属于哪一层，又提供了@Component的衍生注解：
@Controller （标注在控制层类上）@RestController就已经包含了
@Service （标注在业务层类上）
@Repository （标注在数据访问层类上）后面mybatis会换掉
修改入门案例代码：
Controller层：
@RestController //@RestController = @Controller + @ResponseBody public class EmpController { @Autowired //运行时,从IOC容器中获取该类型对象,赋值给该变量 private EmpService empService ; @RequestMapping("/listEmp") public Result list(){ //1. 调用service, 获取数据 List<Emp> empList = empService.listEmp(); //3. 响应数据 return Result.success(empList); } }Service层：
@Service public class EmpServiceA implements EmpService { @Autowired //运行时,从IOC容器中获取该类型对象,赋值给该变量 private EmpDao empDao ; @Override public List<Emp> listEmp() { //1. 调用dao, 获取数据 List<Emp> empList = empDao.listEmp(); //2. 对数据进行转换处理 - gender, job empList.stream().forEach(emp -> { //处理 gender 1: 男, 2: 女 String gender = emp.getGender(); if("1".equals(gender)){ emp.setGender("男"); }else if("2".equals(gender)){ emp.setGender("女"); } //处理job - 1: 讲师, 2: 班主任 , 3: 就业指导 String job = emp.getJob(); if("1".equals(job)){ emp.setJob("讲师"); }else if("2".equals(job)){ emp.setJob("班主任"); }else if("3".equals(job)){ emp.setJob("就业指导"); } }); return empList; } }Dao层：
@Repository public class EmpDaoA implements EmpDao { @Override public List<Emp> listEmp() { //1. 加载并解析emp.xml String file = this.getClass().getClassLoader().getResource("emp.xml").getFile(); System.out.println(file); List<Emp> empList = XmlParserUtils.parse(file, Emp.class); return empList; } }
注解 说明 位置 @Controller @Component的衍生注解 标注在控制器类上 @Service @Component的衍生注解 标注在业务类上 @Repository @Component的衍生注解 标注在数据访问类上（由于与mybatis整合，用的少） @Component 声明bean的基础注解 不属于以上三类时，用此注解一般是不知道实现类是那一层 注意事项：
声明bean的时候，可以通过value属性指定bean的名字，如果没有指定，默认为类名首字母小写。
使用以上四个注解都可以声明bean，但是在springboot集成web开发中，声明控制器bean只能用@Controller。
（2）组件扫描
问题：使用前面学习的四个注解声明的bean，一定会生效吗？
答案：不一定。（原因：bean想要生效，还需要被组件扫描）
下面我们通过修改项目工程的目录结构，来测试bean对象是否生效：
运行后报错：
为什么没有找到bean对象呢？
使用四大注解声明的bean，要想生效，还需要被组件扫描注解@ComponentScan扫描
@ComponentScan注解虽然没有显式配置，但是实际上已经包含在了引导类声明注解 @SpringBootApplication 中，==默认扫描的范围是SpringBoot启动类所在包及其子包==。
解决方案：手动添加@ComponentScan注解，指定要扫描的包（不推荐使用@ComponentScan，还是按照标准的三层架构的目录结构放的好）
5.DI详解
在入门程序案例中，我们使用了@Autowired这个注解，完成了依赖注入的操作，而这个Autowired翻译过来叫：自动装配。
@Autowired注解，默认是按照类型进行自动装配的（去IOC容器中找某个类型的对象，然后完成注入操作）
入门程序举例：在EmpController运行的时候，就要到IOC容器当中去查找EmpService这个类型的对象，而我们的IOC容器中刚好有一个EmpService这个类型的对象，所以就找到了这个类型的对象完成注入操作。
那如果在IOC容器中，存在多个相同类型的bean对象，会出现什么情况呢？
程序运行会报错
（1）多个相同类型bean的问题
如何解决上述问题呢？Spring提供了以下几种解决方案：
@Primary
@Qualifier
@Resource
第一种：在实现类的@Service,@Repository或@Component上面添加@Primary
设置bean的优先级
第二种：在@Autowired注解上面添加@Qualifier声明使用的bean类型名字（首字母小写）
@Qualifier注解不能单独使用，必须配合@Autowired使用
第三种：使用@Resource注解：是按照bean的名称进行注入。通过name属性指定要注入的bean的名称。
（2）面试题 ： @Autowird 与 @Resource的区别
@Autowired 是spring框架提供的注解，而@Resource是JDK提供的注解
@Autowired 默认是按照类型注入，而@Resource是按照名称注入
扫一扫
1137
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
