beanFactory与ApplicationContext

Spring IOC 实现原理

IOC: Inversion of Control ,即 "控制反转" ， 不是什么技术，而是一种思想。原先需要自行实例化的对象， 交给IOC容器去实现。那么控制反转，谁被控制？ 谁被反转 ？

在传统的JavaSE程序中，直接在类的内部通过new关键字来创建对象的实例，是程序主动去创建依赖对象，而IOC有一个专门的容器，来创建这些对象，由IOC容器来控制对象的创建，依赖对象也是容器帮忙查找创建并进行注入，对象只是被动的接受，依赖对象的获取被反转了。它还有一个更加形象的名字叫 依赖注入。

注入方式：

• 接口注入
• setter
• 构造器注入

IOC容器的设计与实现有两种：BeanFactory和ApplicationContext

IOC容器的两个容器设计系列：。

• 实现了BeanFactory接口的简单容器系列，只是实现了容器最基本的功能
• Applic ationContext应用上下文，作为容器的高级形态存在。除了具有基本的功能外，还增加了许多面向框架的特性，同时对应用环境做了许多适配。

BeanFactory

BeanFactory为IOC容器具体实现指定了基本的规范，换句话说BeanFactory是最顶层的类，它有三个子类，ListableBeanFactory、HierarchicalBeanFactory和AutowireCapableBeanFactory接口。但是它们最终生成了一个默认的实现类DefaultListableBeanFactory。

BeanFactory并不关心bean是如何定义，怎样被加载的，当我们需要bean的时候，直接来取就可以了。对于工厂来说，我只需要关心有没有产品，对于产品是怎么产生，怎么制作的，那是工人干的事，工厂并不关心。定义的都是最核心的接口，如getBean()，从容器中获取实例。

ApplicationContext

ApplicationContext是Spring提供的一个高级的IOC容器，除了提供基本IOC容器的功能外，还能为用户提供：

• 支持信息源，可以实现国际化
• 访问资源
• 支持应用事件
• ApplicationContext中提供的附加服务

二者区别

1.BeanFactroy采用的是延迟加载形式来注入Bean的，即只有在使用到某个Bean时(调用getBean())，才对该Bean进行加载实例化，这样，我们就不能发现一些存在的Spring的配置问题。而ApplicationContext则相反，它是在容器启动时，一次性创建了所有的Bean。这样，在容器启动时，我们就可以发现Spring中存在的配置错误。 相对于基本的BeanFactory，ApplicationContext 唯一的不足是占用内存空间。当应用程序配置Bean较多时，程序启动较慢。

BeanFacotry延迟加载,如果Bean的某一个属性没有注入，BeanFacotry加载后，直至第一次使用调用getBean方法才会抛出异常；而ApplicationContext则在初始化自身是检验，这样有利于检查所依赖属性是否注入；所以通常情况下我们选择使用 ApplicationContext。
应用上下文则会在上下文启动后预载入所有的单实例Bean。通过预载入单实例bean ,确保当你需要的时候，你就不用等待，因为它们已经创建好了。

2.BeanFactory和ApplicationContext都支持BeanPostProcessor、BeanFactoryPostProcessor的使用，但两者之间的区别是：BeanFactory需要手动注册，而ApplicationContext则是自动注册。（Applicationcontext比 beanFactory 加入了一些更好使用的功能。而且 beanFactory 的许多功能需要通过编程实现而 Applicationcontext 可以通过配置实现。比如后处理 bean ， Applicationcontext 直接配置在配置文件即可而 beanFactory 这要在代码中显示的写出来才可以被容器识别。 ）

3.beanFactory主要是面对与 spring 框架的基础设施，面对 spring 自己。而 Applicationcontex 主要面对与 spring 使用的开发者。基本都会使用 Applicationcontex 并非 beanFactory 。