【Java】Spring ——用【注解】更快捷的存储 / 获取Bean对象

前言

本人是一个普通程序猿!分享一点自己的见解,如果有错误的地方欢迎各位大佬莅临指导,如果你也对编程感兴趣的话，互关一下，以后互相学习，共同进步。这篇文章能够帮助到你的话,劳请大家点赞转发支持一下!

一、存储 Bean 对象

上篇文章中，向Spring容器中添加对象，还要去配置文件里手动添加，这貌似并不比new便捷。

而Spring项目中呢，往往采用更加便捷的 “注解” 来向Spring容器中添加对象。

类注解

要想将 对象存储到 Spring 中，一共有两种注解类型可以实现：

• 类注解： @Controller、@Service、@Repository、@Component、@Configuration 。
• 方法注解： @Bean。

为什么有五个类注解

类注解一共有五个，但是这五个类注解的功能可以说是一模一样。

那么功能一样，有一个不就好了，为什么还要有五个呢？

这其中的道理，就好像笔记本类型，有轻薄本，办公本，游戏本。
他们不也都是笔记本吗，为什么还要分成三种呢？
因为人们可以从这个类型就看出笔记本更适合干什么。
轻薄本，更加轻薄，便于携带。
办公本，更加适合办公。
游戏本，性能更强，适用于打游戏，与一些需要生产力的场景(视频渲染，建模等)。

所以为什么会有五个功能相同的类注解呢？
在一个项目的开发中，往往需要多名程序员协同开发，
而这五个类注解的目的就是为了让 程序员看到类注解，就能直接了解当前类的用途。

• @Controller：业务逻辑层，负责校验参数的合法性。
• @Service：服务层，负责业务组装。
• @Repository：数据持久层，负责实际业务处理。
• @Configuration：配置层，负责存储配置类。
• @Component：工具层，负责存储工具类。

查看 @Controller、@Service、@Repository、@Configuration 的源码可以发现，这些注解里面都有注解@Component，所以 这四个注解都是@Component的子类 。

• 五个类注解功能相同，下面就只拿@Controller注解做例子讲解了！！！

使用类注解存储对象

配置扫描路径(重中之重)

在配置文件(这里我的配置文件是spring-config.xml)中，添加一行代码即可。

<content:component-scan base-package=""></content:component-scan>

此时Spring就 只会扫描这个路径对应的包中的注解，以及子包中有注解的类 ，并将注解类添加到容器中。

举例
我路径对应的包是test包，所以此时：
Spring
只会扫描test包中的类，以及test的子包 demo包中的类。

不会扫描与test包同级的School类，也不会扫描与test包同级的example包中的类。

扫描路径也是为了提升性能，在实际开发中，一个项目可能包含许多类，如果都扫描的话，那么就会影响性能，因此就有了扫描路径，只扫描该路径下的类。

• 注意注意注意!!! 不在扫描路径的包中的类，即便是这个包上一级中的类，同级的类，同一级包中的类，即便添加了注解，也不会被存储到Spring容器中！！！！！！！！！！！
• 可以配置多个扫描路径！！！Spring会同时将这些路径中的注解放到容器中。

添加注解存储 Bean 对象

五各类注解的使用方法相同，只拿@Controller注解做示范，想用其他注解，使用方法相同。

添加注解存储对象有两种方式：

注解中设置名字
这个value相当于给注解设置名字，然后根据名字在容器中查找取出对象。

有两种设置名字的写法，这两种写法都一样。

注解中不给参数
此时就会根据类名来给你一个默认的名字。下面咱们看下给默认名字方法的源码。
如果 类名的第一个字母与第二个字母都是大写 ，那么他的 默认名字是原类名 。
如果 类名的第一个字母与第二个字母有一个不是大写或都不是大写 ，那么他的 默认名字是首字母小写的类名。

方法注解

配置扫描路径(重中之重)

上述类注解配置扫描路径，这一个扫描路径可以同时供类注解与方法注解使用，配置方法与类注解一致。

使用方法注解存储对象

类注解是添加到某个类上的，而方法注解是放到某个方法上的，如以下代码的实现。

方法注解的作用，就是将这个方法返回的对象存储到容器中。

拿下面两个类举例：

方法注解有两点需要注意
1️⃣方法注解要搭配类注解使用。
不搭配类注解使用>
可以看到不搭配类注解使用就会报错
Spring只会扫描添加了类注解的类 里面是否有方法注解。

搭配类注解使用

方法注解搭配类注解时，类注解同样生效，被类注解标记的类也会被存入容器中 。


2️⃣添加方法注解的方法不能有参数(任何类型的参数都不行)。

下面咱们就来讲一讲方法注解的命名吧！

方法注解@Bean，可以设置value与name设置哪个都行，都当名字用。
值得注意的是方法注解可以设置多个名字，当然也可以不设置名字。

不设置名字

设置一个名字

设置多个名字

• 注意！！！ 当你设置名字后，默认命名就失效了！！再用默认命名就会抛出异常
  

二、获取 Bean 对象

获取 bean 对象也叫做对象装配，是把对象取出来放到某个类中，有时候也叫对象注入。（是放到类里！！ ）

对象装配（对象注入）的实现方法有以下 3 种

• 属性注入
• Setter注入
• 构造方法注入

@Autowired

这三种方式都可以由注解@Autowired实现的，只是实现方式不同 。

下面就用IoC容器模拟实现一对一家教的老师分配学生的场景来讲解三种注入方法。
所需要用到的类，Student(代表一个学生)，Students(学生表)，Teacher(表示一个教师)，App(启动类/测试类)

Student类

Students类，通过方法注解@Bean将Student对象添加到IoC容器中。

Teacher类，在里面通过给student变量注入对象来演示三种对象注入的方式。

属性注入

使用示例：
Teacher类中的Student类型的student变量，就通过属性注入的方法，在IoC容器中注入了对象 。
属性注入的工作原理就是通过你变量的类型，去IoC容器中找寻匹配的类型然后注入到对应的变量中！

BUG
假如IoC容器中有两个相同变量的类型，此时就会有BUG。
修改Students代码，让他向IoC容器中添加两个相同类型的对象。

解决方案1️⃣：使变量名与@Bean的名字相同。

解决方案2️⃣：@Autowired配合@Qualifier一起使用

属性注入的优缺点：
优点 ：
使用简单。


缺点 ：
1️⃣：无法注入final修饰的变量。

2️⃣：通用性问题，只适用于IoC容器。
修改代码，Teacher类不在IoC容器中
此时就不会再进行属性注入了！

3️⃣：更容易违背单一设计原则

Setter注入

使用示例：

setter注入的工作原理就是通过你方法参数的类型，去IoC容器中找寻匹配的类型然后注入到参数中！
工作原理与属性注入相同，所以BUG也相同，解决方案也相同。

BUG
假如IoC容器中有两个相同变量的类型，此时就会有BUG。
修改Students代码，让他向IoC容器中添加两个相同类型的对象。


解决方案1️⃣：使参数列表的变量名与@Bean的名字相同。
解决方案2️⃣：@Autowired配合@Qualifier一起使用

setter注入的优缺点：
优点 ：
通常Setter只Set一个属性，所以Setter注入更符合单一设计的原则。


缺点 ：
1️⃣：无法注入final修饰的变量。
2️⃣：setter注入的对象可以被改变，因为setter是一个方法，可能会被调用多次，因此注入的对象就被改变了。

构造方法注入

使用示例：

构造方法注入的工作原理就是通过构造方法方法参数的类型，去IoC容器中找寻匹配的类型然后注入到参数中！
工作原理与属性注入相同，所以BUG也相同，解决方案也一半相同。

BUG
假如IoC容器中有两个相同变量的类型，此时就会有BUG。
修改Students代码，让他向IoC容器中添加两个相同类型的对象。


解决方案：使参数列表的变量名与@Bean的名字相同。

构造方法注入的优缺点：
优点 ：
1️⃣可以注入final修饰的变量
2️⃣：注入的对象不会被修改，因为构造方法只加载一次。
3️⃣：构造方法注入可以保证注入对象完全初始化。
4️⃣：构造方法注入通用性更好。


缺点 ：
1️⃣：写法比属性注入复杂。
2️⃣：使用构造方法注入，无法解决循环依赖的问题。

@Resource

@Resource与@Autowired的使用方式方法一模一样，但是这两个注解也是有区别的。

@Resource与@Autowired的区别
1️⃣ 出身不同 ：@Resource来自于JDK，@Autowired来自于Spring框架。
2️⃣ 支持参数不同 ：@Resource支持很多参数设置，@Autowired只支持一个参数设置。(下篇文章介绍)
3️⃣ 使用上的区别 ：@Resource不支持构造方法注入，@Autowired支持构造方法注入。
4️⃣ IDEA兼容性不同 ：@Autowired在专业版IDEA中可能会误报，@Resource不会。

总结

以上就是今天要讲的内容，本文介绍了使用注解更快捷便利的存储获取Bean对象！

路漫漫不止修身，也养性。