Spring的IOC

什么是Spring IOC?

        IOC(Inversion of Control)控制反转，把传统上由程序代码直接操控的对象的调用权交给容器，通过容器来实现对象组件的装配和管理。所谓的“控制反转”概念就是对组件对象控制权的转移，从程序代码本身转移到了外部容器。

        至于什么是组件大家只要了解我们所写的程序的功能模块是由组件进行组合完成的就可以啦，对象不一定是组件，但是组件一定是对象。正所谓，万物皆对象。

IOC容器

        通过定义我们可以知道首先IOC是一个容器，一个装配管理对象的容器。也就是说组件的创建、存储、调用、销毁都由IOC容器来负责。

控制反转反转的是什么？

        控制反转反转的是资源获取的方向。传统的资源获取方式是组件主动的获取所需要的资源。而通过控制反转以后，IOC容器会主动的将资源发送给我们需要的组件。我们只需要做相应的声明和配置就好了，完全不用考虑他中间可能经历的与我们业务功能开发无关的事情。

依赖注入DI

        依赖注入（Dependency Injection，DI）和控制反转含义相同，它们是从两个角度描述的同一个概念，可以说DI是IOC的一种具体实现。

BeanFactory

         下面均为原作者对其定义的解释，懒得看就直接看最后。

ApplicationContext

        为应用程序提供配置的中央接口。这在应用程序运行时是只读的，但如果实现支持，则可以重新加载。
ApplicationContext 提供：
        用于访问应用程序组件的 Bean 工厂方法。继承自ListableBeanFactory 。
        以通用方式加载文件资源的能力。继承自ResourceLoader接口。
        向注册的侦听器发布事件的能力。继承自ApplicationEventPublisher接口。
        解决消息的能力，支持国际化。继承自MessageSource接口。
        从父上下文继承。后代上下文中的定义将始终具有优先权。这意味着，例如，整个 Web 应用程序可以使用单个父上下文，而每个 servlet 都有自己的子上下文，该子上下文独立于任何其他 servlet。
        除了标准的BeanFactory生命周期功能之外，ApplicationContext 实现还检测和调用ApplicationContextAware bean 以及ResourceLoaderAware 、 ApplicationEventPublisherAware和MessageSourceAware bean。

ApplicationContext的主要实现类

ClassPathXmlApplicationContext

        独立的 XML 应用程序上下文，从类路径中获取上下文定义文件，将普通路径解释为包含包路径的类路径资源名称（例如“mypackage/myresource.txt”）。对于测试工具以及嵌入在 JAR 中的应用程序上下文很有用。
配置位置默认值可以通过AbstractRefreshableConfigApplicationContext.getConfigLocations()覆盖，配置位置可以表示具体文件，如“/myfiles/context.xml”或 Ant 样式模式，如“/myfiles/*-context.xml”（参见AntPathMatcher javadoc 获取模式详细信息）。
注意：在多个配置位置的情况下，以后的 bean 定义将覆盖之前加载的文件中定义的那些。这可以用来通过额外的 XML 文件故意覆盖某些 bean 定义。
这是一个简单的、一站式便利的ApplicationContext。考虑将GenericApplicationContext类与XmlBeanDefinitionReader结合使用，以实现更灵活的上下文设置。

FileSystemXmlApplicationContext

        独立的 XML 应用程序上下文，从文件系统或 URL 中获取上下文定义文件，将普通路径解释为相对文件系统位置（例如“mydir/myfile.txt”）。对于测试工具以及独立环境很有用。
注意：普通路径将始终被解释为相对于当前 VM 工作目录，即使它们以斜杠开头。 （这与 Servlet 容器中的语义一致。）使用显式的“file:”前缀来强制使用绝对文件路径。
配置位置默认值可以通过AbstractRefreshableConfigApplicationContext.getConfigLocations()覆盖，配置位置可以表示具体文件，如“/myfiles/context.xml”或 Ant 样式模式，如“/myfiles/*-context.xml”（参见AntPathMatcher javadoc 获取模式详细信息）。
注意：在多个配置位置的情况下，以后的 bean 定义将覆盖之前加载的文件中定义的那些。这可以用来通过额外的 XML 文件故意覆盖某些 bean 定义。
这是一个简单的、一站式便利的ApplicationContext。考虑将GenericApplicationContext类与XmlBeanDefinitionReader结合使用，以实现更灵活的上下文设置。

ConfigurableApplicationContext

        大多数（如果不是所有）应用程序上下文都将实现 SPI 接口。除了ApplicationContext接口中的应用程序上下文客户端方法之外，还提供了配置应用程序上下文的工具。
配置和生命周期方法被封装在这里，以避免使它们对 ApplicationContext 客户端代码显而易见。本方法只应由启动和关闭代码使用。

WebApplicationContext

        为 Web 应用程序提供配置的接口。这在应用程序运行时是只读的，但如果实现支持，则可以重新加载。
        该接口在通用 ApplicationContext 接口中增加了一个getServletContext()方法，并定义了一个 众所周知的应用程序属性名称，该名称必须在引导过程中绑定到根上下文。
与通用应用程序上下文一样，Web 应用程序上下文是分层的。每个应用程序有一个根上下文，而应用程序中的每个 servlet（包括 MVC 框架中的调度程序 servlet）都有自己的子上下文。
除了标准的应用程序上下文生命周期功能之外，WebApplicationContext 实现还需要检测ServletContextAware bean 并相应地调用setServletContext方法。

ClassPathXmlApplicationContext	通过读取类路径下的 XML 格式的配置文件创建 IOC 容器对象
FileSystemXmlApplicationContext	通过文件系统路径读取 XML 格式的配置文件创建 IOC 容器对象
ConfigurableApplicationContext	ApplicationContext 的子接口，包含一些扩展方法 refresh() 和 close() ，让 ApplicationContext 具有启动、关闭和刷新上下文的能力。
WebApplicationContext	专门为 Web 应用准备，基于 Web 环境创建 IOC 容器对象，并将对象引入存入 ServletContext 域中。