1.1.2 IoC能做什么
IoC不是一种技术，只是一种思想，一个重要的面向对象编程的法则，它能指导我们如何设计出松耦合、更优良的程序。传统应用程序都是由我们在类内部主动创建依赖对象，从而导致类与类之间高耦合，难于测试；有了IoC容器后，把创建和查找依赖对象的控制权交给了容器，由容器进行注入组合对象，所以对象与对象之间是松散耦合，这样也方便测试，利于功能复用，更重要的是使得程序的整个体系结构变得非常灵活。
其实IoC对编程带来的最大改变不是从代码上，而是从思想上，发生了“主从换位”的变化。应用程序原本是老大，要获取什么资源都是主动出击，但是在IoC/DI思想中，应用程序就变成被动的了，被动的等待IoC容器来创建并注入它所需要的资源了。
IoC很好的体现了面向对象设计法则之一—— 好莱坞法则：“别找我们，我们找你”；即由IoC容器帮对象找相应的依赖对象并注入，而不是由对象主动去找。
2.1.3 IoC和DI
DI—Dependency Injection，即“依赖注入”：是组件之间依赖关系由容器在运行期决定，形象的说，即由容器动态的将某个依赖关系注入到组件之中。依赖注入的目的并非为软件系统带来更多功能，而是为了提升组件重用的频率，并为系统搭建一个灵活、可扩展的平台。通过依赖注入机制，我们只需要通过简单的配置，而无需任何代码就可指定目标需要的资源，完成自身的业务逻辑，而不需要关心具体的资源来自何处，由谁实现。
理解DI的关键是：“谁依赖谁，为什么需要依赖，谁注入谁，注入了什么”，那我们来深入分析一下：
●谁依赖于谁：当然是应用程序依赖于IoC容器；
●为什么需要依赖：应用程序需要IoC容器来提供对象需要的外部资源；
●谁注入谁：很明显是IoC容器注入应用程序某个对象，应用程序依赖的对象；
●注入了什么：就是注入某个对象所需要的外部资源（包括对象、资源、常量数据）。
IoC和DI由什么关系呢？其实它们是同一个概念的不同角度描述，由于控制反转概念比较含糊（可能只是理解为容器控制对象这一个层面，很难让人想到谁来维护对象关系），所以2004年大师级人物Martin Fowler又给出了一个新的名字：“依赖注入”，相对IoC 而言，“依赖注入”明确描述了“被注入对象依赖IoC容器配置依赖对象”。
2.2.1 IoC容器的概念
IoC容器就是具有依赖注入功能的容器，IoC容器负责实例化、定位、配置应用程序中的对象及建立这些对象间的依赖。应用程序无需直接在代码中new相关的对象，应用程序由IoC容器进行组装。在Spring中BeanFactory是IoC容器的实际代表者。
Spring IoC容器如何知道哪些是它管理的对象呢？这就需要配置文件，Spring IoC容器通过读取配置文件中的配置元数据，通过元数据对应用中的各个对象进行实例化及装配。一般使用基于xml配置文件进行配置元数据，而且Spring与配置文件完全解耦的，可以使用其他任何可能的方式进行配置元数据，比如注解、基于java文件的、基于属性文件的配置都可以。
那Spring IoC容器管理的对象叫什么呢？
2.2.2 Bean的概念
由IoC容器管理的那些组成你应用程序的对象我们就叫它Bean， Bean就是由Spring容器初始化、装配及管理的对象，除此之外，bean就与应用程序中的其他对象没有什么区别了。那IoC怎样确定如何实例化Bean、管理Bean之间的依赖关系以及管理Bean呢？这就需要配置元数据，在Spring中由BeanDefinition代表，后边会详细介绍，配置元数据指定如何实例化Bean、如何组装Bean等。概念知道的差不多了，让我们来做个简单的例子。
传统应用程序设计中所说的依赖一般指“类之间的关系”，那先让我们复习一下类之间的关系：
泛化：表示类与类之间的继承关系、接口与接口之间的继承关系；
实现：表示类对接口的实现；
依赖：当类与类之间有使用关系时就属于依赖关系，不同于关联关系，依赖不具有“拥有关系”，而是一种“相识关系”，只在某个特定地方（比如某个方法体内）才有关系。
关联：表示类与类或类与接口之间的依赖关系，表现为“拥有关系”；具体到代码可以用实例变量来表示；
聚合：属于是关联的特殊情况，体现部分-整体关系，是一种弱拥有关系；整体和部分可以有不一样的生命周期；是一种弱关联；
组合：属于是关联的特殊情况，也体现了体现部分-整体关系，是一种强“拥有关系”；整体与部分有相同的生命周期，是一种强关联；
Spring IoC容器的依赖有两层含义：Bean依赖容器和容器注入Bean的依赖资源：
Bean依赖容器：也就是说Bean要依赖于容器，这里的依赖是指容器负责创建Bean并管理Bean的生命周期，正是由于由容器来控制创建Bean并注入依赖，也就是控制权被反转了，这也正是IoC名字的由来，此处的有依赖是指Bean和容器之间的依赖关系。
容器注入Bean的依赖资源：容器负责注入Bean的依赖资源，依赖资源可以是Bean、外部文件、常量数据等，在Java中都反映为对象，并且由容器负责组装Bean之间的依赖关系，此处的依赖是指Bean之间的依赖关系，可以认为是传统类与类之间的“关联”、“聚合”、“组合”关系。
为什么要应用依赖注入，应用依赖注入能给我们带来哪些好处呢？
动态替换Bean依赖对象，程序更灵活：替换Bean依赖对象，无需修改源文件：应用依赖注入后，由于可以采用配置文件方式实现，从而能随时动态的替换Bean的依赖对象，无需修改java源文件；
更好实践面向接口编程，代码更清晰：在Bean中只需指定依赖对象的接口，接口定义依赖对象完成的功能，通过容器注入依赖实现；
更好实践优先使用对象组合，而不是类继承：因为IoC容器采用注入依赖，也就是组合对象，从而更好的实践对象组合。
- 采用对象组合，Bean的功能可能由几个依赖Bean的功能组合而成，其Bean本身可能只提供少许功能或根本无任何功能，全部委托给依赖Bean，对象组合具有动态性，能更方便的替换掉依赖Bean，从而改变Bean功能；
- 而如果采用类继承，Bean没有依赖Bean，而是采用继承方式添加新功能，，而且功能是在编译时就确定了，不具有动态性，而且采用类继承导致Bean与子Bean之间高度耦合，难以复用。
增加Bean可复用性：依赖于对象组合，Bean更可复用且复用更简单；
降低Bean之间耦合：由于我们完全采用面向接口编程，在代码中没有直接引用Bean依赖实现，全部引用接口，而且不会出现显示的创建依赖对象代码，而且这些依赖是由容器来注入，很容易替换依赖实现类，从而降低Bean与依赖之间耦合；
代码结构更清晰：要应用依赖注入，代码结构要按照规约方式进行书写，从而更好的应用一些最佳实践，因此代码结构更清晰。
从以上我们可以看出，其实依赖注入只是一种装配对象的手段，设计的类结构才是基础，如果设计的类结构不支持依赖注入，Spring IoC容器也注入不了任何东西，从而从根本上说“如何设计好类结构才是关键，依赖注入只是一种装配对象手段”。
3.4 Bean的作用域
什么是作用域呢？即“scope”，在面向对象程序设计中一般指对象或变量之间的可见范围。而在Spring容器中是指其创建的Bean对象相对于其他Bean对象的请求可见范围。
Spring提供“singleton”和“prototype”两种基本作用域，另外提供“request”、“session”、“global session”三种web作用域；Spring还允许用户定制自己的作用域。
一、singleton：指“singleton”作用域的Bean只会在每个Spring IoC容器中存在一个实例，而且其完整生命周期完全由Spring容器管理。对于所有获取该Bean的操作Spring容器将只返回同一个Bean
二、prototype：即原型，指每次向Spring容器请求获取Bean都返回一个全新的Bean，相对于“singleton”来说就是不缓存Bean，每次都是一个根据Bean定义创建的全新Bean
三、request作用域：表示每个请求需要容器创建一个全新Bean。比如提交表单的数据必须是对每次请求新建一个Bean来保持这些表单数据，请求结束释放这些数据。
四、session作用域：表示每个会话需要容器创建一个全新Bean。比如对于每个用户一般会有一个会话，该用户的用户信息需要存储到会话中，此时可以将该Bean配置为web作用域。
基于xml配置需要进行bean定义和其依赖bean信息的配置，依赖bean信息配置有setter方法注入和构造器注入，需要在xml文件中进行配置，自动装配方式也需要在xml中配置，有基于setter的byName和byType和基于构造器的contructor。
为了消除xml文件的配置繁琐的工作量引入了注解的方式
@Required注解仅使用于bean属性的setter方法
*这个注解仅仅表示，受影响的bean属性必须在装配时被填充，通过在bean定义或通过自动装配一个明确的属性值
在整个应用中不是特别的常用，因为@autowired(required=true)也能强制该属于被注入一个明确的值。
@Autowired 自动装配，三种方式：1.通过field反射 2.通过构造器注入 3.通过setter注入
*放在字段上是基于xml文件配置的自动装配所不具备的，在Spring2.5以后引入注解后的一种方式，原理为通过反射机制来给bean注值。
优点：你可以在属性中使用 @Autowired 注解来除去 setter 方法，简洁方便
缺点：a.这样不符合JavaBean的规范，而且很有可能引起空指针；
b.同时也不能将对象标为final的；
c.类与DI容器高度耦合，我们不能在外部使用它；
d.类不通过反射不能被实例化（例如单元测试中），你需要用DI容器去实例化它，这更像集成测试；
*通过构造器注入，消除了基于xml配置的构造器注入的配置，直接在构造器上加入该注解，原理相同
缺点：假如我们需要注入的对象特别多的时候，我们的构造器就会显得非常的冗余、不好看，非常影响美观和可读性，维护起来也较为困难；
*通过setter方法注入，消除了基于xml配置的setter注入的配置，直接在setter方法上加入该注解，原理相同。
缺点：那么你将不能将属性设置为final。
来自Spring官方文档的建议：
在Spring 3.x 中，Spring团队建议我们使用setter来注入：
大致是说大量的构造器参数会显得非常笨重，尤其是当属性是可选的时候。setter方法可以使类的对象在后来重新配置或者重新注入。提供所有的依赖意味着对象总是返回一个完全初始化状态的client客户端(调用)。缺点是对象变得不那么适合重新配置和重新注入。
而在Spring 4.x 中，Spring团队不再建议我们使用setter来注入，改为了constructor：
Spring团队通常建议使用构造器来注入，因为它允许一个应用程序组件实现为不可变对象，并确保所需的依赖项不是空。此外构造器注入组件总是返回一个完全初始化状态的client客户端(调用)。附注，大量的构造函数参数是一个糟糕的代码习惯，看起来也很坏，这意味着类可能有太多的责任，应该被重构，以更好地解决适当的关注点分离。
setter方法只应该主要的用在可以在类中指定合理的默认值的可选的依赖关系。否则，用到依赖的所有地方都应该进行非空检查。setter注入的一个好处是，setter方法使类的对象可以在之后重新配置或者重新注入。
总结：
1.强制性的依赖性或者当目标不可变时，使用构造函数注入（应该说尽量都使用构造器来注入）
2.可选或多变的依赖使用setter注入（建议可以使用构造器结合setter的方式来注入）
3.在大多数的情况下避免field域注入（感觉大多数同学可能会有异议，毕竟这个方式写起来非常简便，但是它的弊端确实远大于这些优点）
4.Spring 4.3+ 的同学可以试一试构造器的隐式注入，采用此方式注入后，使得我们的代码更优雅，更独立，减少了对Spring的依赖性。
@Autowired注入首先根据byType注入，当类型大于1时在根据byName注入，若byName失败则抛出异常，此时需要和@Qualifier注解配合使用;
@Qualifier
*按类型自动装配可能多个bean实例的情况，可以使用Spring的@Qualifier注解缩小范围（或指定唯一），也可以用于指定单独的构造器参数或者方法参数；
*可用于注解集合类型变量
Spring提供通过扫描类路径中的特殊注解类来自动注册Bean定义。同注解驱动事务一样需要开启自动扫描并注册Bean定义支持，使用<context:component-scan>标签来表示需要要自动注册Bean定义，而通过base-package属性指定扫描的类路径位置。
Spring自带的@Component注解及扩展@Repository、@Service、@Controller
@Scope 配置bean在spring容器（IOC容器）中的生命周期