Spring bean工厂

    一提到Spring，首先窜进我们脑海的想必一定是IoC了，早在2004年，Martin Fowler就提出了“哪些方面的控制被反转了？”---“依赖对象的获得被反转了”，他的结论。 基于这个结论，也就出现了后来的DI(依赖注入)。对于我们长期面向对象的程序猿而言，面向对象编程中，对象的生命周期和对象之间的依赖关系的管理无疑是往往最让我们 头疼的问题，其实XWork之前也提出了“创造”出一个额外的编程元素---容器来解决这些问题，(其实也就是IoC，不过的Spring的迅速崛起，XWork也放弃在于Spring竞争开发)。

    那么为什么Spring会这么大红大紫这么多年呢？我们知道在那个没有Spring的年代，如果合作对象的引用或依赖关系的管理由具体的对象来完成，代码的高度耦合和可测试 性的降低，在我们对于一个复杂业务的开发可谓是灾难性的。在面向对象编程中，对象封装了数据和对数据的处理，而对象的依赖关系常常体现在对象数据和对象方法的依赖上， 而一旦我们将依赖关系的管理交给IoC来处理，不但代码得到很好的解耦，而且对于可测试性来说也是质的飞越。

   至此，Spring IoC的地位已经毋庸置疑，然而对于我们使用Spring的人来说IoC到底是什么东东呢？我们可以说BeanFactory就是我们能看到IoC容器。BeanFactory其实更 像是IoC容器的一个标准，Spring里提供了给我们行行色色的IoC容器，当然他们都是为了方便我们能够在不能资源位置、不同的层面、不同的形式的定义信息来建立我们的IoC 容器。那么首先先让我们来看看BeanFactory这个标准是怎么定义的吧：

	public interface BeanFactory {
	//这里是对FactoryBean进行转义 如果不加“&”正常按照bean的名字
	//检索FactoryBean得到的是其getObject()构造的对象
	String FACTORY_BEAN_PREFIX = "&";
	//根据bean的名字检索从IoC容器中得到bean的实例
	Object getBean(String name) throws BeansException;
	//根据bean的名字和Class类型来检索bean的实例，与上面那个方法不同在于根据名字
	//取到的bean和Class类型不匹配的话会抛出异常
	<T> T getBean(String name, Class<T> requiredType) throws BeansException;
	//根据Class类型检索bean的实例
	<T> T getBean(Class<T> requiredType) throws BeansException;
	//重载getbean(String name)方法，可变参数主要用来指定是否
	//显示使用静态工厂方法创建一个原型(prototype)bean
	Object getBean(String name, Object... args) throws BeansException;
	//判断IoC容器中是否包含指定name的bean
	boolean containsBean(String name);
	//判断指定名字的bean是否是单例bean
	boolean isSingleton(String name) throws NoSuchBeanDefinitionException;
	//判断指定名字的bean是否是原型bean
	boolean isPrototype(String name) throws NoSuchBeanDefinitionException;
	//判断指定名字的bean是否匹配指定的Class类型
	boolean isTypeMatch(String name, Class<?> targetType) throws NoSuchBeanDefinitionException;
	//根据指定的名字获取bean的Class类型
	Class<?> getType(String name) throws NoSuchBeanDefinitionException;
	//获取指定名字bean的所有别名(alias)
	String[] getAliases(String name);
}

     正如我们所说的BeanFactory只是一个IoC容器的规范，它并不关心你是如何定位、如何加载、如何解析资源，它只是为我们定义了一个IoC的一个 基本的行为规范。这个就像是我们去商店买东西一样，我们关心的是我们买到的什么东西，我们并不关心工厂是怎么生产出这些商品的一样。 在Spring IoC的设计中，我们最常见的俩个主要容器系列是，像ListableBeanFactory、HierarchicalBeanFactory、AutowireCapableBeanFactory、 DefaultListableBeanFactory等等这些继承了BeanFactory的简单容器，另一方面，还有像ApplicationContext这样除了继承BeanFactory规范外，还 新增了像国际化、资源的访问、应用事件的支持以及其他的附加服务。相比简单的BeanFactory，ApplicationContext形式的IoC容器更便于我们开发时 作为IoC容器的基本形式。

    了解了IoC容器的系列，想毕我们日常的大部分需求无出其右，接下先一睹为快BeanFactory的“家族族谱”

 

对于高级IoC容器，到底高端在哪呢？

 

    显然ApplicationContext通过集成MessageSource、ResourceLoader、ApplicationEventPublisher接口，在BeanFactory的基础上 为我们提供了更加丰富多彩的功能。

     在这些Spring提供的各式各样的IoC容器的基础上，Spring通过定义BeanDefinition来管理基于Spring应用中的各种对象之间的依赖关系， 其实在面向对象的编程中，所有的功能都是建立在通过数据对现实进行抽象的基础之上的。而BeanDefinition正是Spring IoC容器用来管理 这些对象之间复杂依赖关系的核心数据结构，那么BeanDefinition的继承结构是什么样的？

 

   其实纵观整个Spring的结构，觉得分析Spring的过程就好比是在看一场演出，有宽敞的舞台(Context),表演精湛的演员(Bean),为演员提供精致的道具(Core)。 刚刚我们已经看见了这些演员的模样，那这样演员都是师从何处呢？

 

    我们都知道，在面向对象的世界里，任何行为都需要抽象成对象的形式表现出来。在Spring的使用中，我们一般都是将对象之间的依赖关系通过xml或者properties的 形式表现出来，然后Spring会通过自己的方式将他们读取、装载形成对象，也就是我们眼前表演精湛的演员们。

 

    然而表演再精湛的演员，他同样需要一个大的舞台(Context)来展现自己，就行我们自己一样，大家其实能力都差不多，只不过“三分能耐六分运气一份贵人扶持”... ... 最后我们再来理一理这个舞台的结构，至于 演员的道具(core)下篇继续...

 

其中： WebApplicationContext:为Web准备的Context，可直接访问ServletContext ConfigurableApplicationContext:该Context是可修改的Context，在构建Context时用户可以动态添加或修改已有配置