Spring学习（十）BeanFactory VS ApplicationContext

BeanFactory是Spring框架最核心的接口，它提供了高级IoC的配置机制。

ApplicationContext建立在BeanFactory基础之上，提供了更多面向应用的功能，它提供了国际化支持和框架事件体系，更易于创建实际应用一般成BeanFactory为IoC容器，而称ApplicationContext为应用上下文。但有时为了方便，我们也将其成为Spring容器。

Spring通过一个描述文件来描述Bean和Bean之间的依赖关系,然后利用java语言的反射机制实例化Bean并建立Bean之间的依赖关系。

Spring的IoC容器在完成这些底层工作的基础之上,还提供Bean的实例缓存、生命周期管理、Bean的实例代理、事件发布以及资源装载等高级服务。

首先先来介绍一下 BeanFactory

BeanFactory和传统的类工厂还是有所不同的:

传统的类工厂只负责一个或者几个类的实例

而BeanFactory是类通用工厂，他可以创建并管理各种类的通用对象。这些可被创建和管理的类对象本身并没有什么特别之处。他们仅仅是一个POJO，Spring称这些被创建和管理的对象为Bean。所有可以被Spring容器实例化和管理的类都可以被成为JavaBean

观察一下BeanFactory的体系结构:

BeanFactory位于类结构树的顶端，其主要的方法就是getBean，该方法从容器中返回特定名称的Bean。

BeanFactory的功能通过其他的接口得到不断的扩展，接下来对涉及到的其他接口进行声明：

1.    XmlBeanFactory

2.    ListableBeanFactory：定义了访问容器中bean的基本信息的若干方法，如查看bean的个数，获取某一类型bean的配置名称，或者查看容器中是否包含某一bean等等这些方法。

3.    HierarhicalBeanFactory：父子级联IoC容器的接口，子容器可以通过接口方法访问父容器。

4.    ConfigurableBeanFactory：增强了IoC容器的可定制性。他定义了设置类装载器、属性编辑器、容器初始化后置处理器等等方法。

5.    AutowireCapableBeanFactory：将容器中的bean按照某种规则比如:按照名称匹配，按照类型匹配等等来进行自动装配的方法。

6.    SingletonBeanFactory：在容器运行期间向容器注册单实例bean的方法

7.    BeanDefinitionRegistry：Spring配置文件中，每一个bean节点元素在Spring容器里面都通过一个BeanDefinition对象来表示，他描述了Bean的配置信息。BeanDefinitionRegistry接口提供了向容器手工注册BeanDefinition对象的方法。

BeanFactory的初始化顺序如下:

1.    首先创建相关的配置文件

2.    Spring通过BeanFactory来装载配置文件

3.    启动IoC容器

4.    获取Bean实例

其中：通过BeanFactory启动IoC实例时并不会初始化配置文件当中定义的Bean，初始化的操作发生在第一个调用的时候。对于单实例的Bean来说BeanFactory会缓存Bean的实例，所以第二次使用getBean的方法时就可以直接从IoC容器的缓存中来获取Bean的实例了。

另外，在初始化BeanFactory时必须为其提供一种日志框架，我们使用的是Log4J，即在类路径下提供Log4J的配置文件，这样启动Spring容器时才不会报错。

接下来介绍 ApplicationContext

ApplicationContext由BeanFactory派生而来，提供了更多面向实际应用的功能。在BeanFactory中，很多功能需要以编程的方式方式实现，而在ApplicationContext中则可以通过配置的方式实现。接下来介绍一下ApplicationContext的实现类以及类体系结构。

具体实现类：

1.    ClassPathXmlApplicationContext：从类路径中加载配置文件

2.    FileSystemXmlApplicationContext：从文件系统中来加载配置文件

3.    ConfigurableApplicationContext：扩展自ApplicationContext，新增加了两个方法reflesh、close。这让ApplicationContext具有启动、刷新和关闭应用上下文的能力。在应用上下文关闭的情况下调用reflesh即可启动应用上下文，在已经启动的状态下调用reflesh即可清除缓存并且重新装载配置信息，调用close方法则可以关闭应用上下文。

接下来我们了解下ApplicationContext的类集成体系

ApplicationContext通过许多其他接口扩展了BeanFactory的功能，其中包括：

1.    ApplicationEventPublisher：他让容器拥有发布应用上下文事件的功能

2.    MessageSource：他为容器提供了I18N国际化信息访问的功能

3.    ReaourcePatternResolver：可以通过带前缀Ant风格的资源类文件路径来装载Spring的配置文件。

4.    LifeCycle：Spring2.0加入的接口，提供start和stop两个方法，主要用于处理异步控制的过程。

和BeanFactory初始化相似，ApplicationContext的初始化也很简单，根据配置文件路径不同可以选择不同的实现类加载：

•    配置文件在类路径下：ClassPathXmlApplicationContext

•    配置文件放在文件系统路径下：FileSystemXmlApplicationContext

在获取了ApplicationContext实例之后，就可以像BeanFactory一样来调用getBean来返回Bean的实例。

ApplicationContext的初始化和BeanFactory有一个很大的区别：

BeanFactory在初始化容器的时候并没有实例化Bean，直到第一次访问Bean时才实例化目标Bean。

ApplicationContext在初始化应用上下文时就初始化了所有单实例Bean。

因此，ApplicationContext的初始化时间会比BeanFactory长

ApplicationContext和BeanFactory另一个最大的不同之处在于：

前者会利用Java反射机制自动识别出配置文件中定义的BeanPostProcessor、InstantiationAwareBeanPostProssor和BeanFactoryProcessor并自动将他们注册到应用上下文中。

而后者需要在代码中通过手工调用addBeanPostProcessor方法来进行注册。

这也就是我们在开发中经常使用ApplicationContext而不使用BeanFactory的原因之一。

在ApplicationContext中我们只需要在配置文件中通过Bean定义工厂后处理器和Bean后处理器他们就会按预期的方式来运行。

总结：

对于BeanFactory和ApplicationContext两者的用途，我们可以进行简单的划分：

BeanFacroty是Spring框架的基础设施，是面向Spring本身的。

ApplicationContext是面向使用Spring框架的开发者。

几乎所有的场合我们都直接使用ApplicationContext而非底层的BeanFactory。