Spring 深入——IoC 容器 01( 二 ) _生活百科

<bean/> 标签来创建 Bean，实际上是在描述一个 BeanDefinition，而当 IoC 容器通过 Reader 定位到需要的 BeanDefinitieon，则是根据 Reader 解析好的 BeanDefinition 信息来创建我们描述好的 Bean 对象，并进行管理。

BeanDefinitionReader:
读取 Spring 配置文件中的内容，并将其转换为 IoC 容器的内部数据结构：BeanDefinition 。
在 XBF 中 XBDR 就是 BDR 的一个具体实现，Spring 的配置内容是 XML，所以根据 XML 的形式来转换 BeanDefinition 。

Resource：
Spring 统一对不同来源的资源进行底层抽象，方便统一管理不同的资源。
通过简单的观察继承关系和部分源码，大概分析是 Spring 对不同来源的资源统一进行底层资源封装或抽象。
再通过不同的实现类对具体的资源面向用户提高具体的服务接口。

【Spring 深入——IoC 容器 01】通过解释或者百度几个关键类，我们应该能理解 IoC 容器初始化的简单过程。
观察 XBF 的源码可以发现除了使用 XBDR 对象进行资源的解析和加载，并没有看到关于 IoC 容器的初始化过程，看到 super(parentBeanFactory) 这句代码调用了父类 —— DefaultListableBeanFactory 的构造方法，从而完成了 IoC 容器的构建。那么我们初步可以分析出 DefaultListableBeanFactory 应该是 XBF IoC 容器创建的重要对象。实际上它也是个基本 IoC 容器。
直到这里我们就简单分析出了 XBF IoC 容器的创建过程。
loadBeanDefinition()通过 reader 解析好的 Bean 信息加载到 BeanFactory （IoC 容器）中。
ApplicationContext对于开发人员来说，例如开发一个 Web 服务端，如果要开发人员手动控制 Bean 的配置和容器的建立过程，无疑是非常痛苦的，所以 Spring 帮我们定义了许多已经实现好的容器，并且这些容器面向的需求也不一样，相对于已经实现的简单 BeanFactory 容器，不能很大程度上满足开发人员的需求，所以 ApplicationContext 无疑是更好的选择。
之前介绍了 ApplicationContext 是在基本 IoC 容器上，进行了更大程度的扩展，让 IoC 容器面向框架，提供更多的服务，方便开发人员的使用，更加专注于业务逻辑的实现。同时也是对 IoC 容器一次全面的更新和扩展。
AC 扩展了一些接口，在基础 IoC 容器上添加了附加功能，这些额外的功能为 AC 提供了 BeanFactory 不具备的特性：

支持不同的信息源：扩展了 MessageSource 接口，支持国际化，为开发多语言版本的应用提供服务。
访问资源：主要体现在对 ResourceLoader 和 Resource 的支持上，让我们可以获从不同的地方获取 Bean 资源，主要是可以在不同的 I/O 途径获取 Bean 定义信息。这里的指的是具体的 ApplicationContext 容器，一般来说都是继承了 DefaultResourceLoader 的子类，因为 DefaultResourceLoader 是 AbstractApplicationContext的基类。
支持应用事件
继承了接口 ApplicationEventPublisher，从而在上下文中引入了事件机制，这些事件结合 Bean 的生命周期对 Bean 管理提供了便利。
提供其他附加服务
这些其他的附加服务，使得基本的 IoC 的功能更加丰富，使它的使用是一种面向框架的使用风格。

设计原理：
以常用的 FileSystemXmlApplicationContext 的实现为例说明 ApplicationContext 容器的设计原理。
通过观察 FSXAC 的源码，AC 容器的主要功能已经在 FSXAC 的基类 AbstractXmlApplicationContext 中实现了，所以 FSXAC 只要实现与自身设计相关的两个功能。
功能一：如果直接使用 FSXAC，对于实例化这个应用上下文的支持，同时启动 IoC 容器的