spring（3）-阿里云开发者社区

spring（2）https://developer.aliyun.com/article/1530430

2.3、基于注解管理bean

2.3.1、实验一：标记与扫描

①注解

和 XML 配置文件一样，注解本身并不能执行，注解本身仅仅只是做一个标记，具体的功能是框架检测

到注解标记的位置，然后针对这个位置按照注解标记的功能来执行具体操作。

本质上：所有一切的操作都是Java代码来完成的，XML和注解只是告诉框架中的Java代码如何执行。

举例：元旦联欢会要布置教室，蓝色的地方贴上元旦快乐四个字，红色的地方贴上拉花，黄色的地方贴上气球。

班长做了所有标记，同学们来完成具体工作。墙上的标记相当于我们在代码中使用的注解，后面同学们做的工作，相当于框架的具体操作。

②扫描

Spring 为了知道程序员在哪些地方标记了什么注解，就需要通过扫描的方式，来进行检测。然后根据注解进行后续操作。

③新建Maven Module

<dependencies>
    <!-- 基于Maven依赖传递性，导入spring-context依赖即可导入当前所需所有jar包 -->
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>5.3.1</version>
    </dependency>
    <!-- junit测试 -->
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.12</version>
        <scope>test</scope>
    </dependency>
</dependencies>

④创建Spring配置文件

⑤标识组件的常用注解

@Component：将类标识为普通组件

@Controller：将类标识为控制层组件

@Service：将类标识为业务层组件

@Repository：将类标识为持久层组件

问：以上四个注解有什么关系和区别？

通过查看源码我们得知，@Controller、@Service、@Repository这三个注解只是在@Component注解的基础上起了三个新的名字。

对于Spring使用IOC容器管理这些组件来说没有区别。所以@Controller、@Service、@Repository这

三个注解只是给开发人员看的，让我们能够便于分辨组件的作用。,其本质其实都是一样的

注意：虽然它们本质上一样，但是为了代码的可读性，为了程序结构严谨我们肯定不能随便胡乱标记。

⑥扫描组件

直接设置注解,然后ioc里面配置扫描主件

<context:component-scan base-package="com.atguigu.spring">  
  
</context:component-scan>

情况一：最基本的扫描方式

<context:component-scan base-package="com.atguigu">
</context:component-scan>

情况二：指定要排除的组件

<context:component-scan base-package="com.atguigu">
    <!-- context:exclude-filter标签：指定排除规则 -->
    <!--
        type：设置排除或包含的依据
        type="annotation"，根据注解排除，expression中设置要排除的注解的全类名
        type="assignable"，根据类型排除，expression中设置要排除的类型的全类名
    -->
    <context:exclude-filter type="annotation"expression="org.springframework.stereotype.Controller"/>
    <!--<context:exclude-filter type="assignable"expression="com.atguigu.controller.UserController"/>-->
</context:component-scan>

情况三：仅扫描指定组件

默认情况下 use-default-filters=“true” 即包内所有类都扫描

<context:component-scan base-package="com.atguigu" use-default-filters="false">
    <!-- context:include-filter标签：指定在原有扫描规则的基础上追加的规则 -->
    <!-- use-default-filters属性：取值false表示关闭默认扫描规则 -->
    <!-- 此时必须设置use-default-filters="false"，因为默认规则即扫描指定包下所有类 -->
    <!--
        type：设置排除或包含的依据
        type="annotation"，根据注解排除，expression中设置要排除的注解的全类名
        type="assignable"，根据类型排除，expression中设置要排除的类型的全类名
     -->
    <context:include-filter type="annotation"expression="org.springframework.stereotype.Controller"/>
    <!--<context:include-filter type="assignable"expression="com.atguigu.controller.UserController"/>-->
</context:component-scan>

[!note]

一般我们使用的是指定排除的组件,情况二和情况三不能同时存在,只能选择一个

⑨组件所对应的bean的id

在我们使用XML方式管理bean的时候，每个bean都有一个唯一标识，便于在其他地方引用。现在使用

注解后，每个组件仍然应该有一个唯一标识。

默认情况

类名首字母小写就是bean的id。例如：UserController类对应的bean的id就是userController。

自定义bean的id

可通过标识组件的注解的value属性设置自定义的bean的id

@Service(“userService”)//默认为userServiceImpl

public class UserServiceImpl implements UserService {}

[!note]

一般我们都是根据类型获取,因为自动装配只装配当前类型的唯一一个

2.3.2、实验二：基于注解的自动装配

之前是基于xml的自动装配,但是现在我们使用注解了,就不能使用之前的那种自动装配了

使用注解的方式,不用为当前的成员变量设置get和set方法

①场景模拟

参考基于xml的自动装配

在UserController中声明UserService对象

在UserServiceImpl中声明UserDao对象

②@Autowired注解

在成员变量上直接标记@Autowired注解即可完成自动装配，不需要提供setXxx()方法。以后我们在项

目中的正式用法就是这样。

@Controller
public class UserController {
    @Autowired
    private UserService userService;
    public void saveUser(){
        userService.saveUser();
    }
}

public interface UserService {
    void saveUser();
}
@Service
public class UserServiceImpl implements UserService {
    @Autowired
    private UserDao userDao;
    @Override
    public void saveUser() {
        userDao.saveUser();
    }
}

public interface UserDao {
  void saveUser();
}

@Repository
public class UserDaoImpl implements UserDao {
    @Override
    public void saveUser() {
        System.out.println("保存成功");
    }
}

③@Autowired注解其他细节

@Autowired注解可以标记在构造器和set方法上

====

@Controller
public class UserController {
    private UserService userService;
    @Autowired
    public UserController(UserService userService){
        this.userService = userService;
    }
    public void saveUser(){
        userService.saveUser();
    }
}

@Controller
public class UserController {
    private UserService userService;
    @Autowired
    public void setUserService(UserService userService){
        this.userService = userService;
    }
    public void saveUser(){
        userService.saveUser();
    }
}

[!note]

@Autowired注解的原理

a>默认通过byType的方式，在IOC容器中通过类型匹配某个bean为属性赋值

④@Autowired工作流程

首先根据所需要的组件类型到IOC容器中查找

能够找到唯一的bean：直接执行装配
如果完全找不到匹配这个类型的bean：装配失败
和所需类型匹配的bean不止一个

没有@Qualifier注解：根据@Autowired标记位置成员变量的变量名作为bean的id进行匹配
能够找到：执行装配
找不到：装配失败
使用@Qualifier注解：根据@Qualifier注解中指定的名称作为bean的id进行匹配
能够找到：执行装配
找不到：装配失败

@Controller
public class UserController {
    @Autowired
    @Qualifier("userServiceImpl")
    private UserService userService;
    public void saveUser(){
        userService.saveUser();
    }
}

@Autowired中有属性required，默认值为true，因此在自动装配无法找到相应的bean时，会装

配失败

可以将属性required的值设置为true，则表示能装就装，装不上就不装，此时自动装配的属性为

默认值

但是实际开发时，基本上所有需要装配组件的地方都是必须装配的，用不上这个属性。

3、AOP

3.1、场景模拟

3.1.1、声明接口

声明计算器接口Calculator，包含加减乘除的抽象方法

public interface Calculator {
    int add(int i, int j);
    int sub(int i, int j);
    int mul(int i, int j);
    int div(int i, int j);
}

3.1.2、创建实现类

public class CalculatorPureImpl implements Calculator {
    @Override
    public int add(int i, int j) {
        int result = i + j;
        System.out.println("方法内部 result = " + result);
        return result;
    }
    @Override
    public int sub(int i, int j) {
        int result = i - j;
        System.out.println("方法内部 result = " + result);
        return result;
    }
    @Override
    public int mul(int i, int j) {
        int result = i * j;
        System.out.println("方法内部 result = " + result);
        return result;
    }
    @Override
    public int div(int i, int j) {
        int result = i / j;
        System.out.println("方法内部 result = " + result);
        return result;
    }
}

3.1.3、创建带日志功能的实现类

public class CalculatorLogImpl implements Calculator {
    @Override
    public int add(int i, int j) {
        System.out.println("[日志] add 方法开始了，参数是：" + i + "," + j);
        int result = i + j;
        System.out.println("方法内部 result = " + result);
        System.out.println("[日志] add 方法结束了，结果是：" + result);
        return result;
    }
    @Override
    public int sub(int i, int j) {
        System.out.println("[日志] sub 方法开始了，参数是：" + i + "," + j);
        int result = i - j;
        System.out.println("方法内部 result = " + result);
        System.out.println("[日志] sub 方法结束了，结果是：" + result);
        return result;
    }
    @Override
    public int mul(int i, int j) {
        System.out.println("[日志] mul 方法开始了，参数是：" + i + "," + j);
        int result = i * j;
        System.out.println("方法内部 result = " + result);
        System.out.println("[日志] mul 方法结束了，结果是：" + result);
        return result;
    }
    @Override
    public int div(int i, int j) {
        System.out.println("[日志] div 方法开始了，参数是：" + i + "," + j);
        int result = i / j;
        System.out.println("方法内部 result = " + result);
        System.out.println("[日志] div 方法结束了，结果是：" + result);
        return result;
    }
}

3.1.4、提出问题

这些方法中的日志公共实现逻辑是重复的,我们最好把方法单独拿出来,但是又不是像jdbc中连续执行的代码,这是在方法体中分散执行的代码,我们并不好抽取出来

①现有代码缺陷

针对带日志功能的实现类，我们发现有如下缺陷：

对核心业务功能有干扰，导致程序员在开发核心业务功能时分散了精力
附加功能分散在各个业务功能方法中，不利于统一维护

②解决思路

解决这两个问题，核心就是：解耦。我们需要把附加功能从业务功能代码中抽取出来。

③困难

解决问题的困难：要抽取的代码在方法内部，靠以前把子类中的重复代码抽取到父类的方式没法解决。所以需要引入新的技术。

3.2、代理模式

3.2.1、概念

①介绍

二十三种设计模式中的一种，属于结构型模式。它的作用就是通过提供一个代理类，让我们在调用目标方法的时候，不再是直接对目标方法进行调用，而是通过代理类间接调用。让不属于目标方法核心逻辑的代码从目标方法中剥离出来——解耦。调用目标方法时先调用代理对象的方法，减少对目标方法的调用和打扰，同时让附加功能能够集中在一起也有利于统一维护。

使用代理后：

②生活中的代理

广告商找大明星拍广告需要经过经纪人

③相关术语

代理：将非核心逻辑剥离出来以后，封装这些非核心逻辑的类、对象、方法。
目标：被代理“套用”了非核心逻辑代码的类、对象、方法。

3.2.2、静态代理

创建静态代理类：

public class CalculatorStaticProxy implements Calculator {
    // 将被代理的目标对象声明为成员变量
    private Calculator target;
    public CalculatorStaticProxy(Calculator target) {
        this.target = target;
    }
    @Override
    public int add(int i, int j) {
        // 附加功能由代理类中的代理方法来实现
        System.out.println("[日志] add 方法开始了，参数是：" + i + "," + j);
        // 通过目标对象来实现核心业务逻辑
        int addResult = target.add(i, j);
        System.out.println("[日志] add 方法结束了，结果是：" + addResult);
        return addResult;
    }
}

静态代理确实实现了解耦，但是由于代码都写死了，完全不具备任何的灵活性。就拿日志功能来

说，将来其他地方也需要附加日志，那还得再声明更多个静态代理类，那就产生了大量重复的代

码，日志功能还是分散的，没有统一管理。

提出进一步的需求：将日志功能集中到一个代理类中，将来有任何日志需求，都通过这一个代理

[!question]

还是只能在方法执行前后添加额外的东西,不能在方法中间,而且还是多个方法都得写这个逻辑功能相同的"日志"的代码

spring（4）https://developer.aliyun.com/article/1530434

spring（3）