JavaEE-Spring-IoCDI
Spring是⼀个开源框架, 他让我们的开发更加简单. 他⽀持⼴泛的应⽤场
景, 有着活跃⽽庞⼤的社区, 这也是Spring能够⻓久不衰的原因.
但是这个概念相对来说, 还是⽐较抽象.
⽤⼀句更具体的话来概括Spring, 那就是: Spring 是包含了众多⼯具⽅法的 IoC 容器
容器是⽤来容纳某种物品的（基本）装置。
⽣活中的⽔杯, 垃圾桶, 冰箱等等这些都是容器.
之前接触的容器
List/Map -> 数据存储容器
Tomcat -> Web 容器
什么是 IoC
IoC 是Spring的核⼼思想, 也是常⻅的⾯试题, 那什么是IoC呢?
其实IoC我们在前⾯已经使⽤了, 我们在前⾯讲到, 在类上⾯添加 @RestController 和 @Controller 注解, 就是把这个对象交给Spring管理, Spring 框架启动时就会加载该类. 把对象交 给Spring管理, 就是IoC思想.
IoC: Inversion of Control (控制反转), 也就是说 Spring 是⼀个"控制反转"的容器.
什么是控制反转呢? 也就是控制权反转. 什么的控制权发⽣了反转? 获得依赖对象的过程被反转了
也就是说, 当需要某个对象时, 传统开发模式中需要⾃⼰通过 new 创建对象, 现在不需要再进⾏创 建, 把创建对象的任务交给容器, 程序中只需要依赖注⼊ (Dependency Injection,DI)就可以了.
这个容器称为：IoC容器. Spring是⼀个IoC容器, 所以有时Spring 也称为Spring 容器.
控制反转是⼀种思想, 在⽣活中也是处处体现.
⽐如⾃动驾驶, 传统驾驶⽅式, ⻋辆的横向和纵向驾驶控制权由驾驶员来控制, 现在交给了驾驶⾃
动化系统来控制, 这也是控制反转思想在⽣活中的实现.
⽐如招聘, 企业的员⼯招聘,⼊职, 解雇等控制权, 由⽼板转交给给HR(⼈⼒资源)来处理
IoC 优势
在传统的代码中对象创建顺序是：Car -> Framework -> Bottom -> Tire
改进之后解耦的代码的对象创建顺序是：Tire -> Bottom -> Framework -> Car
我们发现了⼀个规律，通⽤程序的实现代码，类的创建顺序是反的，传统代码是 Car 控制并创建了Framework，Framework 创建并创建了 Bottom，依次往下，⽽改进之后的控制权发⽣的反转，不再是使⽤⽅对象创建并控制依赖对象了，⽽是把依赖对象注⼊将当前对象中，依赖对象的控制权不再由当前类控制了.
这样的话, 即使依赖类发⽣任何改变，当前类都是不受影响的，这就是典型的控制反转，也就是 IoC 的实现思想。学到这⾥, 我们⼤概就知道了什么是控制反转了, 那什么是控制反转容器呢, 也就是IoC容器
这部分代码, 就是IoC容器做的⼯作.
从上⾯也可以看出来, IoC容器具备以下优点:
资源不由使⽤资源的双⽅管理，⽽由不使⽤资源的第三⽅管理，这可以带来很多好处。第⼀，资源集中管理，实现资源的可配置和易管理。第⼆，降低了使⽤资源双⽅的依赖程度，也就是我们说的耦合度。
资源集中管理: IoC容器会帮我们管理⼀些资源(对象等), 我们需要使⽤时, 只需要从IoC容器中去取 就可以了
在创建实例的时候不需要了解其中的细节, 降低了使⽤资源双⽅的依赖程度, 也就是耦合度.
Spring 就是⼀种IoC容器, 帮助我们来做了这些资源管理.
DI 介绍
学习了IoC, 什么是DI呢?
DI: Dependency Injection(依赖注⼊)
容器在运⾏期间, 动态的为应⽤程序提供运⾏时所依赖的资源，称之为依赖注⼊。
程序运⾏时需要某个资源，此时容器就为其提供这个资源.从这点来看, 依赖注⼊（DI）和控制反转（IoC）是从不同的⻆度的描述的同⼀件事情，依赖注⼊是
从应⽤程序的⻆度来描述, 就是指通过引⼊ IoC 容器，利⽤依赖关系注⼊的⽅式，实现对象之间的解耦.
上述代码中, 是通过构造函数的⽅式, 把依赖对象注⼊到需要使⽤的对象中的
IoC 是⼀种思想，也是"⽬标", ⽽思想只是⼀种指导原则，最终还是要有可⾏的落地⽅案，⽽ DI 就属于具体的实现。所以也可以说, DI 是IoC的⼀种实现.
⽐如说我今天⼼情⽐较好，吃⼀顿好的犒劳犒劳⾃⼰，那么"吃⼀顿好的"是思想和⽬标（是
IoC），但最后我是吃海底捞还是杨国福？这就是具体的实现，就是 DI。
也就是将资源交给spring管理，是ioc，是要用来使用的，那么具体怎么使用就是di。
Bean的存储
在之前的⼊⻔案例中，要把某个对象交给IOC容器管理，需要在类上添加⼀个注解： @Component
⽽Spring框架为了更好的服务web应⽤程序, 提供了更丰富的注解.
共有两类注解类型可以实现：
类注解：@Controller、@Service、@Repository、@Component、@Configuration.
⽅法注解：@Bean.
接下来我们分别来看
其实这些能够将对象交给spring保管的都是component的衍生注解，实现这个功能的就是有component。
从Spring容器中获取对象
ApplicationContext 翻译过来就是: Spring 上下⽂
因为对象都交给 Spring 管理了，所以获取对象要从 Spring 中获取，那么就得先得到 Spring 的上下⽂
关于上下⽂的概念
上学时, 阅读理解经常会这样问: 根据上下⽂, 说⼀下你对XX的理解
在计算机领域, 上下⽂这个概念, 咱们最早是在学习线程时了解到过, ⽐如我们应⽤进⾏线程切换的时候，切换前都会把线程的状态信息暂时储存起来，这⾥的上下⽂就包括了当前线程的信息，等下次该线程⼜得到CPU时间的时候, 从上下⽂中拿到线程上次运⾏的信息
这个上下⽂, 就是指当前的运⾏环境, 也可以看作是⼀个容器, 容器⾥存了很多内容, 这些内容是当前运⾏的环境
获取bean对象的其他⽅式
上述代码是根据类型来查找对象, 如果Spring容器中, 同⼀个类型存在多个bean的话, 怎么来获取呢?ApplicationContext 也提供了其他获取bean的⽅式, ApplicationContext 获取bean对象的功能, 是⽗类BeanFactory提供的功能.
常⽤的是上述1,2,4种, 这三种⽅式,获取到的bean是同一个
其中1,2种都涉及到根据名称来获取对象. bean的名称是什么呢?
Spring bean是Spring框架在运⾏时管理的对象, Spring会给管理的对象起⼀个名字.
⽐如学校管理学⽣, 会给每个学⽣分配⼀个学号, 根据学号, 就可以找到对应的学⽣.
Spring也是如此, 给每个对象起⼀个名字, 根据Bean的名称(BeanId)就可以获取到对应的对象
Bean 命名约定
默认的命名时将类型改成小驼峰，首字母变成小写，如果前面两个字母都是大写的话，那么默认的命名就是类名，也可以通过自定义来对存储的变量命名，就是对componen及其衍生注解添加属性值，这个属性值就是自定义对象名
序开发⼈员不需要为bean指定名称(BeanId), 如果没有显式的提供名称(BeanId)，Spring容器将为该bean⽣成唯⼀的名称.
命名约定使⽤Java标准约定作为实例字段名. 也就是说，bean名称以⼩写字⺟开头，然后使⽤驼峰式⼤⼩写.
也有⼀些特殊情况, 当有多个字符并且第⼀个和第⼆个字符都是⼤写时, 将保留原始的⼤⼩写. 这些规则与java.beans.Introspector.decapitalize (Spring在这⾥使⽤的)定义的规则相同.
地址⼀样, 说明对象是⼀个
获取bean对象, 是⽗类BeanFactory提供的功能
ApplicationContext VS BeanFactory（常⻅⾯试题）
继承关系和功能⽅⾯来说：Spring 容器有两个顶级的接⼝：BeanFactory 和 ApplicationContext。其中 BeanFactory 提供了基础的访问容器的能⼒，⽽ApplicationContext 属于 BeanFactory 的⼦类，它除了继承了 BeanFactory 的所有功能之外，它还拥有独特的特性，还添加了对国际化⽀持、资源访问⽀持、以及事件传播等⽅⾯的⽀持.
从性能⽅⾯来说：ApplicationContext 是⼀次性加载并初始化所有的 Bean 对象，⽽
BeanFactory 是需要那个才去加载那个，因此更加轻量. (空间换时间)
为什么这么多类注解？
这个是和应用分层相互对应的，让程序员看到类注解之后，就能直接了解当前类的⽤途.
@Controller：控制层, 接收请求, 对请求进⾏处理, 并进⾏响应.
@Servie：业务逻辑层, 处理具体的业务逻辑.
@Repository：数据访问层，也称为持久层. 负责数据访问操作
@Configuration：配置层. 处理项⽬中的⼀些配置信息
和每个省/市都有⾃⼰的⻋牌号是⼀样的.
⻋牌号都是唯⼀的, 标识⼀个⻋辆的. 但是为什么还需要设置不同的⻋牌开头呢.⽐如陕西的⻋牌号就是：陕X：XXXXXX，北京的⻋牌号：京X：XXXXXX，甚⾄⼀个省不同的县区也
是不同的，⽐如西安就是，陕A：XXXXX，咸阳：陕B：XXXXXX，宝鸡，陕C：XXXXXX，⼀样.
这样做的好处除了可以节约号码之外，更重要的作⽤是可以直观的标识⼀辆⻋的归属地
序的应⽤分层，调⽤流程如下：
其实这些注解⾥⾯都有⼀个注解 @Component ，说明它们本⾝就是属于 @Component 的"⼦类".
@Component 是⼀个元注解，也就是说可以注解其他类注解，如 @Controller , @Service ,
@Repository 等. 这些注解被称为 @Component 的衍⽣注解.
@Controller , @Service 和 @Repository ⽤于更具体的⽤例(分别在控制层, 业务逻辑层, 持久化层), 在开发过程中, 如果你要在业务逻辑层使⽤ @Component 或@Service，显然@Service是更好的选择
⽐如杯⼦有喝⽔杯, 刷⽛杯等, 但是我们更倾向于在⽇常喝⽔时使⽤⽔杯, 洗漱时使⽤刷⽛杯.
更多资料参考: https://docs.spring.io/spring-framework/reference/core/beans/classpathscanning.html#beans-stereotype-annotations
方法注解 @Bean
注解是添加到某个类上的， 但是存在两个问题:
使⽤外部包⾥的类, 没办法添加类注解
⼀个类, 需要多个对象, ⽐如多个数据源
这种场景, 我们就需要使⽤⽅法注解 @Bean
使用bean注解，注解的方法要满足返回值是需要被spring管理的一个对象，一般都使用public来修饰该方法。
方法注解要配合类注解使用，如果没有类注解，使用了方法注解也是没办法被检索到的。
在 Spring 框架的设计中，⽅法注解 @Bean 要配合类注解才能将对象正常的存储到 Spring 容器中
定义多个对象
对于同⼀个类, 如何定义多个对象呢?
⽐如多数据源的场景, 类是同⼀个, 但是配置不同, 指向不同的数据源.
定义了多个对象，但是如果单纯只靠类名来获取的话会报错，因为定义了多个对象，无法确定到底哪个才是真正要使用的。那么就可以通过名称或者名称和类来获取对象。
重命名 Bean
bean注解和component这些注解所交给spring管理的对象默认名是方法名，方法名是全局唯一的，就算不是同一类也不能重复。
当bean注解的方法需要参数时，会自动从spring所管理的对象中取出对应的参数。
如果该参数为基本类型或者包装类时则不会，而是需要直接对其赋值，可以通过依赖注入，也可以直接声明默认值
但如果所需参数的类被spring管理不止一个，就会报错，那么就需要注解@qualifier来确定依赖注入的参数，或者通过一些配置文件可以直接通过参数名来匹配
@Bean
public ExampleBean(@Qualifier("primaryDs") DataSource dataSource) {
// 明确注入ID为"primaryDs"的DataSource
}
依赖注入
依赖注⼊是⼀个过程，是指IoC容器在创建Bean时, 去提供运⾏时所依赖的资源，⽽资源指的就是对象.
在上⾯程序案例中，我们使⽤了 @Autowired 这个注解，完成了依赖注⼊的操作.
简单来说, 就是把对象取出来放到某个类的属性中.
在⼀些⽂章中, 依赖注⼊也被称之为 "对象注⼊", "属性装配", 具体含义需要结合⽂章的上下⽂来理解
关于依赖注⼊, Spring也给我们提供了三种⽅式:
属性注⼊(Field Injection)
构造⽅法注⼊(Constructor Injection)
Setter 注⼊(Setter Injection）
属性注⼊
属性注⼊是使⽤ @Autowired 实现的，将 Service 类注⼊到 Controller 类中.
构造方法注入
构造⽅法注⼊是在类的构造⽅法中实现注⼊，如下代码所⽰
Setter 注入
Setter 注⼊和属性的 Setter ⽅法实现类似，只不过在设置 set ⽅法的时候需要加上 @Autowired 注
解 ，如下代码所⽰：
三种注入优缺点分析
属性注⼊
优点: 简洁，使⽤⽅便；
缺点:
只能⽤于 IoC 容器，如果是⾮ IoC 容器不可⽤，并且只有在使⽤的时候才会出现 NPE（空指
针异常）
不能注⼊⼀个Final修饰的属性
构造函数注⼊(Spring 4.X推荐)
优点:
可以注⼊final修饰的属性
注⼊的对象不会被修改
依赖对象在使⽤前⼀定会被完全初始化，因为依赖是在类的构造⽅法中执⾏的，⽽构造⽅法
是在类加载阶段就会执⾏的⽅法.
通⽤性好, 构造⽅法是JDK⽀持的, 所以更换任何框架,他都是适⽤的
缺点:
注⼊多个对象时, 代码会⽐较繁琐•
Setter注⼊(Spring 3.X推荐)
优点: ⽅便在类实例之后, 重新对该对象进⾏配置或者注⼊
缺点:
不能注⼊⼀个Final修饰的属性
注⼊对象可能会被改变, 因为setter⽅法可能会被多次调⽤, 就有被修改的⻛险
@Autowired存在的问题
@Autowired 是spring框架提供的注解，⽽@Resource是JDK提供的注解
@Autowired 默认是按照类型注⼊，⽽@Resource是按照名称注⼊. 相⽐于 @Autowired 来说，
@Resource ⽀持更多的参数设置，例如 name 设置，根据名称获取 Bean.
Autowired装配顺序
总结
Spring, Spring Boot 和Spring MVC的关系以及区别
Spring: 简单来说, Spring 是⼀个开发应⽤框架，什么样的框架呢，有这么⼏个标签：轻量级、⼀
站式、模块化，其⽬的是⽤于简化企业级应⽤程序开发.
Spring的主要功能: 管理对象，以及对象之间的依赖关系, ⾯向切⾯编程, 数据库事务管理, 数据访问, web框架⽀持等.
但是Spring具备⾼度可开放性, 并不强制依赖Spring, 开发者可以⾃由选择Spring的部分或者全部, Spring可以⽆缝继承第三⽅框架, ⽐如数据访问框架(Hibernate 、JPA), web框架(如Struts、JSF)
Spring MVC: Spring MVC是Spring的⼀个⼦框架, Spring诞⽣之后, ⼤家觉得很好⽤, 于是按照MVC
模式设计了⼀个 MVC框架(⼀些⽤Spring 解耦的组件), 主要⽤于开发WEB应⽤和⽹络接⼝，所以,
Spring MVC 是⼀个Web框架.
Spring MVC基于Spring进⾏开发的, 天⽣的与Spring框架集成. 可以让我们更简洁的进⾏Web层开发, ⽀持灵活的 URL 到⻚⾯控制器的映射, 提供了强⼤的约定⼤于配置的契约式编程⽀持, ⾮常容易与其他视图框架集成，如 Velocity、FreeMarker等
Spring Boot: Spring Boot是对Spring的⼀个封装,
为了简化Spring应⽤的开发⽽出现的，中⼩型企业，没有成本研究⾃⼰的框架, 使⽤Spring Boot 可以更加快速的搭建框架, 降级开发成本, 让开发⼈员更加专注于Spring应⽤的开发，⽽⽆需过多关注XML的配置和⼀些底层的实现.
Spring Boot 是个脚⼿架, 插拔式搭建项⽬, 可以快速的集成其他框架进来.⽐如想使⽤SpringBoot开发Web项⽬, 只需要引⼊Spring MVC框架即可, Web开发的⼯作是
SpringMVC完成的, ⽽不是SpringBoot, 想完成数据访问, 只需要引⼊Mybatis框架即可.
Spring Boot只是辅助简化项⽬开发的, 让开发变得更加简单, 甚⾄不需要额外的web服务器, 直接⽣成jar包执⾏即可.
最后⼀句话总结: Spring MVC和Spring Boot都属于Spring，Spring MVC 是基于Spring的⼀个
MVC 框架，⽽Spring Boot 是基于Spring的⼀套快速开发整合包.
⽐如图书系统代码中
整体框架是通过SpringBoot搭建的
IoC, DI功能是Spring的提供的
web相关功能是Spring MVC提供的