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