SpringbootWeb请求响应和分层解耦

标签：请求 Controller SpringbootWeb 响应 分层 参数 注解 public String

目录

前言

一、请求（学会使用postman和接收请求参数）

1.后端接口测试工具Postman

（1）引入

（2）介绍

（3）安装和使用

 2.简单参数 

（1）postman发送请求测试

 （2）原始方式接收

（3）SpringBoot方式

（4）Spingboot方式参数名不一致问题

3.实体参数

（1）简单实体

（2）复杂实体

4.数组集合参数

 （1）数组

（2）集合

5.日期参数

 6.JSON参数

7.路径参数

8.Controller接收请求参数用到的注解

二、响应

1.@ResponseBody

2.统一响应结果

 三、案例

1.需求

2.Controller代码 

3.问题分析

 四、分层解耦

1.三层架构

（1）概述

（2） 原案例代码拆分

2.分层解耦

（1）还有耦合问题

（2）解耦思路

3. IOC&DI入门

4.IOC详解

（1）bean声明

（2）组件扫描

 5.DI详解

（1）多个相同类型bean的问题

（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. 数组

2. 集合

 （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格式参数，主要从以下两个方面着手：

1. Postman在发送请求时，如何传递json格式的请求参数

2. 在服务端的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层的代码解耦

• 思路：

  1. 删除Controller层、Service层中new对象的代码

  2. Service层及Dao层的实现类，交给IOC容器管理

  3. 为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是按照名称注入

 

标签：请求,Controller,SpringbootWeb,响应,分层,参数,注解,public,String
From： https://blog.csdn.net/2202_75483664/article/details/141466519