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时用户可以动态添加或修改已有配置

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值