关于spring框架的基本认识及使用

框架

关于框架

​ 框架（Framework）一个框架是一个可复用的设计构件，它规定了应用的体系结构，阐明了整个设计、协作构件之间的依赖关系、责任分配和控制流程，表现为一组抽象类以及其实例之间协作的方法，它为构件复用提供了上下文(Context)关系。

​ 应用框架指的是实现了某应用领域通用完备功能（除去特殊应用的部分） 的底层服务。使用这种框架的编程人员可以在一个通用功能已经实现的基 础上开始具体的系统开发。框架提供了所有应用期望的默认行为的类集合。具体的应用通过重写子类（该子类属于框架的默认行为）或组装对象来支 持应用专用的行为。

​ 你可以将框架理解为现实生活中的“毛胚房”，它已经完成了住房最基础部分的设计，例如打地基、设计住房的基本格局、预留电路、水路的线路接入等……当你使用一个框架时，就相当于得到了一间毛胚房，如果你想住进去，你需要做的事情主要是“装修”，把这个毛胚房加工成你希望的样子。

​ 所以，在软件开发中，使用框架，可以不必关注基础的、通用的功能开发， 因为这些部分在框架中已经处理好了，而且，框架已经实现的部分，通常 比你自行开发的代码更加高效、更加安全、更加健壮。

​ 虽然使用框架对你的开发有很大的帮助，但是，与此同时，你也会受到框架的约束，例如，假设你的“毛胚房”是东西朝向的，你是没有办法通过正常的手段把它变成一个南北朝向的房子的。

关于Spring框架

​ Spring框架主要解决了创建对象、管理对象的问题。

​ 在开发实践中，Spring框架的核心价值在于：开发者可以通过Spring框架提供的机制，将创建对象、管理对象的任务交给Spring来完成，以至于开发者不必再关心这些过程，当需要某个对象时，只需要通过Spring获取对象即可。

​ Spring框架也经常被称之为：Spring容器

​ 在开发实践中，有许多类型的对象、配置值都需要常驻内存、需要有唯一性，或都需要多处使用，自行维护这些对象或值是非常繁琐的，通过Spring框架可以极大的简化这些操作。

在Maven工程中使用Spring框架

​ 当某个项目需要使用Spring框架时，推荐使用Maven工程。

​ 使用Spring框架所需的依赖项是 spring-context，依赖代码为：

<dependency>]()
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>5.3.14</version>
</dependency>

通过spring框架管理对象

创建对象的方式

​ 如果需要Spring管理对象，就必须先创建对象，然后Spring获取到对象才可以进行管理

被Spring管理的对象，通常也称之为Spring Bean

​ 创建对象的方式有2种：

• ​ 通过@Bean方法
• ​ 通过组件扫描

通过@ Bean方法创建对象

编码步骤：

• 创建cn.tedu.spring.SpringBeanFactory类
• 在类中添加方法，方法的返回值类型就是你希望Spring创建并管理的对象的类型，并在此方法中自行编写返 回有效对象的代码
• 在此类上添加**@Configuration**注解
• 在此方法上添加**@Bean**注解
• 配置@Bean注解参数可以指定beanName

示例代码：

package cn.tedu.spring;
@Configuration
public class SpringBeanFactory {
@Bean  //("random")
public Random random() { return new Random();}}

测试运行：

public class SpringRunner {
public static void main(String[] args) {
// 1. 加 载 –这是ApplicationContext接口的实现，通常称之为Spring的应用程序上下文
    Spring AnnotationConfigApplicationContext ac
= new AnnotationConfigApplicationContext(SpringBeanFactory.class);
// 2. 从Spring中获取对象
Random random = (Random) ac.getBean("random");
// 3. 测试使用对象，以便于观察是否获取到了有效的对象
System.out.println("random > " + random);
// 4. 关 闭
ac.close();}}

关于以上代码，你需要知道：

• 在AnnotationConfigApplicationContext的构造方法中，应该将 SpringBeanFactory.class作为参数传入，否则就不会加载SpringBeanFactory类中内容

• 实际上，在以上案例中，SpringBeanFactory类上的@Configuration注解并不是必须的，但@Bean方法的使用规范是将其声明在@Configuration类中

• 在getBean()时，传入的字符串参数"random"是SpringBeanFactory类中的@Bean方法的名称

• 在SpringBeanFactory类中的方法必须添加@Bean注解，其作用是使得Spring框架自动调用此方法，并管理此方法返回的结果

• 关于getBean()方法，此方法被重载了多次，典型的有：

  • Object getBean(String beanName)

• 通过此方法，传入的beanName必须是有效的，否则将导致NoSuchBeanDefinitionException

  • T getBean(Class beanClass);

• 使用此方法时，传入的类型在Spring中必须有且仅有1个对象，如果Spring容器中没有匹配类型的对象，将导致NoSuchBeanDefinitionException，如果有2个或更多，将导致NoUniqueBeanDefinitionException

  • T getBean(String beanName, Class beanClass)

• 此方法仍是根据传入的beanName获取对象，并且根据传入的beanClass进行类型转换

• – 使用的@Bean注解可以传入String类型的参数，如果传入，则此注解对应的方法的返回结果的beanName就是@Bean注解中传入的String参数值，后续调用getBean()方法时，如果需要传入beanName，就应该传入在@Bean注解中配置的String参数值

通过组件扫描创建对象

配置@Component注解参数以指定beanName

@Component 
public class UserMapper { 
}

@Configuration 
@ComponentScan("cn.spring")
public class SpringConfig { 
}

● 测试运行的编码步骤：

– 与前序编写测试运行代码的方式相同

– 调用getBean()获取对象时，传入的beanName是：将UserMapper的类名首字母改为小写，即userMapper

public class SpringRunner {
public static void main(String[] args) {
// 1. 加 载 Spring AnnotationConfigApplicationContext ac
= new AnnotationConfigApplicationContext(SpringConfig.class);
// 2. 从Spring中获取对象
UserMapper userMapper = ac.getBean("userMapper", UserMapper.class);
// 3. 测试使用对象，以便于观察是否获取到了有效的对象
System.out.println("userMapper > " + userMapper);
// 4. 关 闭
ac.close();}

关于以上代码，你需要知道

• 使用@ComponentScan配置的是执行组件扫描的根包，当创建 AnnotationConfigApplicationContext对象时，由于传的SpringConfig添加了此注解，则Spring框架会扫描所配置的包，如果包中有组件类，Spring框架就会创建组件类的对象并管理
• UserMapper类必须在@ComponentScan注解配置的包中，否则Spring框架不会知道此类的存在
• 在UserMapper上的@Component表示此类是个“组件”，如果无此注解，Spring框架不会创建此类的对象
• 在@ComponentScan中配置的包是执行组件扫描的“根包（basePackage）”，在执行时，会扫描此包及其下所有子孙包，例如配置为cn.tedu时，如果存在 cn.tedu.spring、cn.tedu.mybatis、cn.tedu.boot、cn.tedu.boot.mapper、 cn.tedu.boot.controller等包，则这些包都会被扫描
• 你甚至可以把根包配置为cn，也可以完全扫描到以上列举的包，但并不推荐这么做，毕竟你的开发环境中的其它库中的类也是项目的一部分，例如依赖的第三方框架或工具等， 如果这些框架或工具的包名的第1级也是cn，也会被扫描到，尽管不确实是否会导致意外的问题，但这种做法肯定是不对的
• 当getBean()时，由Spring创建的组件类的对象，默认的beanName都是将首字母改为小写
• 以上规则仅适用于：类名中的第1个字母是大写，且第2个字母是小写的情况，如果类名不符合这种情况，则getBean()时传入的名称就是类名（与类名完全相同的字符串）
• 你可以配置@Component注解的参数以指定beanName
• 在创建对象的过程中，Spring会自动调用构造方法来创建对象，其中用到了反射机制，即使构造方法是私有的，也不影响调用
• Spring在许多实现上都使用了反射机制，基本上不会受到访问权限修饰符的影响

选择创建对象的方式

● 以上已经介绍了2种创建对象的方式，相比之下：

1. 通过@Bean方法：需要在配置类中添加@Bean方法，需要Spring管理的对象越多，则需要添加的@Bean方法就越多，虽然每个方法的代码并不复杂，但是当方法的数 量到一定程度后也比较繁琐，不易于管理，这种做法的优点是可以完全自定义对象的创建过程，在@Bean方法内部仍是传统的创建对象的语句
2. 通过组件扫描：只需要配置1次组件扫描，然后各组件类添加组件即可，且各组件类添加组件注解后也可增强语义，所以，无论编码成本还是代码的可读性都更好，这种做法的不足在于“只能适用于自定义的类”，毕竟你不可以在引用的库中的类上添加组件注解

SpringBean的作用域

• 在默认情况下，由Spring Bean的作用域是单例的

• 单例的表现为：实例唯一，即在任意时刻每个类的对象最多只有1个，并且，当对象创建出来之后，将常驻内存，直至Spring将其销毁（通常是 ApplicationContext调用了销毁方法，或程序运行结束）

• 可以通过@Scope注解修改作用域

1. 当通过@Bean方法创建对象时，在方法的声明之前添加@Scope注解
2. 当通过组件扫描创建对象时，在组件类的声明之前添加@Scope注解

@Scope注解

@Scope注解的scopeName属性决定了作用域，此属性与value是互相等效的，所以，通常配置为value属性即可

@Scope注解的scopeName属性的常见取值有：

​ singleton：单例的

事实上这是默认值，在scopeName属性的源码上明确的说明了：Defaults to an empty string “” which implies ConfigurableBeanFactory.SCOPE_SINGLETON，且以上常量的值就是singleton

​ prototype：原型，是非单例的**

● 在默认情况下，单例的Spring Bean是预加载的，必要的话，也可以将其配置为懒加载的

– 如果某个对象本身不是单例的，则不在此讨论范围之内

● 预加载的表现为：加载Spring环境时就会创建对象，即加载Spring配置的环节，会创建对象

● 懒加载的表现为：加载Spring环境时并不会创建对象，而是在第1次获取对象的那一刻再创建对象

@Lazy

● 可以通过@Lazy注解来配置懒加载

1. 当通过@Bean方法创建对象时，在方法的声明之前添加@Lazy注解
2. 当通过组件扫描创建对象时，在组件类的声明之前添加@Lazy注解

● @Lazy注解的value属性是boolean类型的，表示“是否懒加载”

● @Lazy注解的参数是不需要关心的，因为：

​ – 单例的Spring Bean默认就是预加载的，不是懒加载的，所以，保持默认状态时，不使用@Lazy注解即可，并不需要配置为@Lazy(false)

​ – @Lazy注解的value属性默认为true，所以，当需要将单例的Spring Bean配置为懒加载时，只需要添加@Lazy注解即可，并不需要配置为@Lazy(true)

● 预加载的优点：

​ 事先创建好对象，无论何时需要获取对象，都可以直接获取，缺点在于：相当于启动程序时就会创建对象，这样的对象越多， 启动过程就越慢，并且，如果某个对象创建出来以后，在接下来的很长一段时间都不需要使用，而此对象却一直存在于内存中，则是一种浪费

● 懒加载的优点在于：

​ 仅当需要对象时才会创建对象，不会形成浪费，缺点在于：如果当前系统已经负荷较重，需要的对象仍未加载，则会增加系统负担

​ ● 相比而言，在开发实践中，通常认为预加载是更合理的配置

spring总结

• Spring可以将创建出来的对象管理起来，对于开发者而言，当需要某个类的对象时，只需要从Spring容器中获取即可

• 创建对象的方式有2种：

1. 通过@Bean方法：在配置类中自定义方法，返回需要Spring管理的对象，此方法必须添加@Bean注解
2. 通过组件扫描：在配置类中使用@ComponentScan指定需要扫描的包，并确保需要 Spring管理对象的类都在此包或其子孙包下，且这些类必须添加@Component、 @Repository、@Service、@Controller中的其中某1个注解
3. 如果需要Spring管理的是自定义的类的对象，应该使用组件扫描的做法，如果需要 Spring管理的对象的类型不是自定义的，只能使用@Bean方法的做法

• 使用组件扫描时，在@ComponentScan中指定的包是扫描的根包，其子孙包中的类都会被扫描，通常，指定的包不需要特别精准， 但也不宜过于粗糙，你应该事先规划出项目的根包并配置在组件扫描中， 且保证自定义的每个组件类都在此包或其子孙包中
• 在Spring框架的解释范围内，@Component、 @Repository、@Service、@Controller的作用是完全相同的，但语义不同，应该根据类的定位进行选取
• @Configuration是特殊的组件注解，Spring会通过代理模式来处理，此注解应该仅用于配置类
• 使用@Bean方法时，beanName默认是方法名，也可以在@Bean注解中配置参数来指定beanName
• 使用组件扫描时，beanName默认是将类名首字母改为小写的名称（除非类名不符合首字母大写、第2字母小写的规律），也可以在@Component或其它组件注解中配置参数来指定beanName

Spring Bean的作用域默认是预加载的单例的，可以通过 @Scope(“prototype”)配置为“非单例的”，在单例的前提下，可以通过 @Lazy配置为“懒加载的”，通常，保持为默认即可

• 关于配置注解参数：

1. – 如果你需要配置的只是注解的value这1个属性，不需要显式的写出属性名称
2. – 如果你需要配置注解中的多个属性，每个属性都必须显式写出属性名称，包括value属性
3. – 如果你需要配置的注解属性的值是数组类型，当只指定1个值时，可以不使用大括号将值框住，当指定多个值时，多个值必须使用大括号框住，且各值之间使用逗号分隔
4. – 你可以通过查看注解的源代码来了解注解可以配置哪些属性、属性的值类型、默认值
5. – 在注解的源代码中，@AliasFor可理解为“等效于”

自动装配机制

● Spring的自动装配机制表现为：当某个量需要被赋值时，可以使用特定的语法，使得Spring尝试从容器找到合适的值，并自动完成赋值

● 最典型的表现就是在类的属性上添加@Autowired注解，Spring就会尝试从容器中找到合适的值为这个属性赋值

● 除了对属性装配以外，Spring的自动装配机制还可以表现为：如果某个方法是由Spring框架自动调用的（通常是构造方法，或@Bean方法），当这个方法被声明了参数时，Spring框架也会自动的尝试从容器找到匹配的对象，用于调用此方法

● 对方法的参数自动装配时，如果方法有多个参数，各参数的先后顺序是不重要的

● 关于@Autowired的装配机制，首先，会根据需要装配的数据的类型在 Spring容器中统计匹配的Bean（对象）的数量

● 当匹配的Bean数量为0个时，判断@Autowired注解的required属性值

​ true（默认）：装配失败，启动项目时即抛出NoSuchBeanDefinitionException

​ false：放弃自动装配，不会报告异常，后续直接使用此属性时，会出现NPE

● 当匹配的Bean数量为1个时，将直接装配，且装配成功

● 当匹配的Bean数量为多个时：自动尝试按照名称实现装配（即：要求属性名称与beanName相同）

​ – 存在与属性名称匹配的Spring Bean：装配成功

​ – 不存在与属性名称匹配的Spring Bean：装配失败，启动项目时即抛出NoUniqueBeanDefinitionException

● [★★★★★] 当某个属性需要被注入值，且你肯定此值存在于Spring容器中，你可以在属性上添加@Autowired注解，则Spring框架会自动为此属性注入值

● [★★★★★] 如果某个方法是由Spring调用的，当方法体中需要某个值，且你肯定此值存在于Spring容器中，你可以将其声明为方法的参数，则 Spring框架会自动从容器中找到此值并且于调用此方法，如果声明了多个这样的参数，各参数的先后顺序是不重要的

● [★★★★★] 自动装配的前提是Spring会自动创建此类的对象，否则， Spring不可能为属性赋值，也不可能调用类中的方法

● [★★★★★] @Autowired的装配机制的表现是可以根据类型实现装配，并且，当匹配类型的Bean有多个时，还可以根据名称进行匹配，从而实现装配，你需要熟记具体装配机制（由于篇幅较长，请参见前序说明）

IOC与DI

● IoC（Inversion of Control：控制反转）是Spring框架的核心，在传统的开发模式下，是由开发者创建对象、为对象的属性赋值、管理对象的作用域和生命周期等，所以，是开发者拥有“控制权”，当使用了Spring之后，这些都交给Spring框架去完成了，开发者不必关心这些操作的具体实现，所以，称之为“控制反转”

● 无论是创建对象，还是自动装配等等，只要是Spring创建并管理对象的操作，都可以称之为Spring IoC的过程

● **DI（**Dependency Injection：依赖注入）是Spring框架实现IoC的核心实现，当某个类中声明了另一个类的属性（例如在UserController类中声明了UserMapper类型的属性），则称之为依赖（即UserController依赖了 UserMapper），Spring框架会帮你完成依赖项的赋值，只是你在你的代码中看不到赋值过程或赋值符号，所以称之为注入

● 关于IoC与DI的关系，可以描述为：Spring通过DI实现了IoC，所以，IoC是一种目标，而DI是实现此目标的重要手段

关于构造方法

● 当通过组件扫描创建对象时，Spring会自动调用组件类的构造方法，此过程中会使用到反射，所以可以无视构造方法的访问权限

● 如果类中仅有1个构造方法，Spring会自动调用这个构造方法

● 如果类中没有显式的添加构造方法，根据Java的机制，会由编译器添加默认构造方法，相当于有1个构造方法

● 如果类中有多个构造方法，默认情况下，Spring会自动调用无参数构造方法（如果存在的话），如果某个构造方法添加了@Autowired，则Spring会自动调用添加了此注解的构造方法

● 被Spring调用的构造方法是允许有参数的，作为开发者，你需要保证 Spring可以利用自动装配机制为参数注入值（你需要保证Spring容器中存在匹配的值），否则会导致NoSuchBeanDefinitionException