IOC
IOC,官方给的定义是依赖注入(Dependency Injection)或者控制反转(Inversion of Control)。光从字面理解起来还比较拗口,但任何一种模式都是来自人的行为思考方式。想象下日常生产过程,在生产之前是客户下单,单子会详细注明需要的产品,包括产品的各方面规格属性,然后工厂据此生产。
IOC就是一个类似的过程,用户声明要什么,ioc就给用户生产什么。在过程中用户只是给出需求清单,而不用再费劲去new,以及不停设置各种属性。
Spring ioc
Spring-beans是ioc最著名的实现,而且已经没有之一,现在几乎就是ioc的代名词。虽然更多人倾向认为beans只是工厂,context才是容器,但context本身更类似是beans的外观–由它驱动beans,并且对内组合beans的功能;而且context本身也是基于beans之上的。spring最下方最牢靠的地基只有beans,它是spring的基石组件,所有的我们已知的spring组件都是基于它。
spring-beans整体架构
Spring-beans提供的优秀的可扩展能力使spring几乎能包容一切,用户只需遵循spring beans的相关规范–spring.schema定义配置文档的文法规范,spring.handler定义客户化配置的解析工具–就可以将bean接入到spring容器里。Bean接入后还可以通过实现BeanPostProcessor或者init-method对bean做后处理甚至替换bean。
Spring-beans的优秀设计使spring越来越像是一个生态圈,基于beans,aop、context、mvc、annotation等强大的组件都被接入进来,除此还有一些优秀的第三方组件,例如dubbo等。
以aop为例,先在parse阶段对aop的配置生成Advised bean(Advisor),然后在所有bean的后处理阶段get Advised bean,并通过filter判断是否适应于当前bean,适用则会对bean织入advice。后面如果有时间会专门做篇aop,这里不再继续深入。
Dubbo和aop略有区别,dubbo的扩展选择了init method中的afterPropertiesSet,所有严格意义上dubbo是无法去spring的,虽然dubbo声明是可以,但其实只能不适用spring功能,而不能去spring jar,dubbo bean在init阶段生成ref,其实也是个代理–封装了远程访问的细节。有兴趣的可以访问我之前写的dubbo相关的文章。
Bean定义
Spring-beans的核心实体是BeanDefinition和BeanFactory。前者映射我们的定义,后者则是依据定义生产bean的工厂。
上图是spring beans的静态结构图,更多是偏重于bean解析,因为1. 理解了bean解析也就理解了一半spring扩展能力;2.BeanFactory的复杂不在于类之间的组织结构,而在于复杂的调用链路,也就没必要是静态结构方面做过多说明。需要说明的是,这只是概念模型,并不完全映射到类,