SpringIoc体系结构设计

IOC容器的整体功能

从这个图仔细体会Spring框架加载Bean的过程. 有一个全局观.

1:加载Bean的配置（比如xml配置 注解配置)不同类型资源的加载，解析成生成统一Bean的定义.

2:根据Bean的定义加载生成Bean的实例，并放置在Bean容器中

3:对容器中的Bean提供统一的管理和调用

BeanFactory和BeanRegistry：IOC容器功能规范和Bean的注册

BeanFactory：

工厂模式定义了IOC容器的基本功能规范.

/* 例如，如果命名的bean是FactoryBean，则获取将返回Factory，而不是Factory返回的实例。
	 */
	String FACTORY_BEAN_PREFIX = "&";


	/* @throws BeansException if the bean could not be obtained
	 * 根据bean的名字和Class类型等来得到bean实例
	 */
	Object getBean(String name) throws BeansException;

	/*
	 * 根据bean的名字和类型获取指定的bean.
	 */
	<T> T getBean(String name, Class<T> requiredType) throws BeansException;

	/* @since 2.5
	 */
	Object getBean(String name, Object... args) throws BeansException;

	/* @see ListableBeanFactory
	 */
	<T> T getBean(Class<T> requiredType) throws BeansException;

	
	<T> T getBean(Class<T> requiredType, Object... args) throws BeansException;

	
	<T> ObjectProvider<T> getBeanProvider(Class<T> requiredType);

	/*
	 * 返回指定bean的provider.
	 */
	<T> ObjectProvider<T> getBeanProvider(ResolvableType requiredType);

	/* 
	 * 检查工厂中是否包含给定name的bean,或者外部注册的bean.
	 */
	boolean containsBean(String name);

	/*
	 * 判断所给的name的bean是否为单例.
	 */
	boolean isSingleton(String name) throws NoSuchBeanDefinitionException;

	/*
	 * 检查所给的name的bean是否为原型bean.
	 */
	boolean isPrototype(String name) throws NoSuchBeanDefinitionException;

	/* @see #getType
	 */
	boolean isTypeMatch(String name, ResolvableType typeToMatch) throws NoSuchBeanDefinitionException;

	/* 
	 * 判断所给name的类型与type是否匹配.
	 */
	boolean isTypeMatch(String name, Class<?> typeToMatch) throws NoSuchBeanDefinitionException;

	/*
	 * 获取给定name的bean的类型.
	 */
	@Nullable
	Class<?> getType(String name) throws NoSuchBeanDefinitionException;

	
	@Nullable
	Class<?> getType(String name, boolean allowFactoryBeanInit) throws NoSuchBeanDefinitionException;

	/*
	 * 返回给定name的bean的名字.
	 */
	String[] getAliases(String name);

}

BeanRegistry：

向IOC容器手工注册 BeanDefinition 对象的方法.

这是这两个接口的关系.很明了.

BeanFactory为何要定义这么多层次的接口.定义了哪些接口. 

主要是为了区分在 Spring 内部在操作过程中对象的传递和转化过程中，对对象的数据访问所做的限制。

ListableBeanFactory：

该接口定义了访问容器中 Bean 基本信息的若干方法，如查看Bean 的个数、获取某一类型 Bean 的配置名、查看容器中是否包括某一 Bean 等方法.

HierarchicalBeanFactory：

父子级联 IoC 容器的接口，子容器可以通过接口方法访问父容器； 通过 HierarchicalBeanFactory 接口， Spring 的 IoC 容器可以建立父子层级关联的容器体系，子容器可以访问父容器中的 Bean，但父容器不能访问子容器的 Bean。Spring 使用父子容器实现了很多功能，比如在 Spring MVC 中，展现层 Bean 位于一个子容器中，而业务层和持久层的 Bean 位于父容器中。这样，展现层 Bean 就可以引用业务层和持久层的 Bean，而业务层和持久层的 Bean 则看不到展现层的 Bean.

ConfigurableBeanFactory：

是一个重要的接口，增强了 IoC 容器的可定制性，它定义了设置类装载器、属性编辑器、容器初始化后置处理器等方法.

ConfigurableListableBeanFactory:

ListableBeanFactory 和 ConfigurableBeanFactory的融合.

AutowireCapableBeanFactory：

定义了将容器中的 Bean 按某种规则（如按名字匹配、按类型匹配等）进行自动装配的方法.

如何将Bean注册到BeanFactory中？BeanRegistry

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

BeanDefinition：各种Bean对象及其相互的关系

1.BeanDefinition : 定义了各种Bean对象及其相互的关系.

2.BeanDefinitionReader: 这是BeanDefinition的解析器.

3.BeanDefinitionHolder :这是BeanDefination的包装类，用来存储BeanDefinition，name以及aliases等.

 

 

从这些类图就足以看出他们之间的关系. 

ApplicationContext：IOC接口设计和实现

IoC容器的接口类是ApplicationContext，很显然它必然继承BeanFactory对Bean规范（最基本的ioc容器的实现）进行定义。而ApplicationContext表示的是应用的上下文，除了对Bean的管理外，还至少应该包含了

1:访问资源： 对不同方式的Bean配置（即资源）进行加载。(实现ResourcePatternResolver接口)

2:国际化: 支持信息源，可以实现国际化。（实现MessageSource接口）

3:应用事件: 支持应用事件。(实现ApplicationEventPublisher接口)

ApplicationContext接口的设计

1:HierarchicalBeanFactory 和 ListableBeanFactory： ApplicationContext 继承了 HierarchicalBeanFactory 和 ListableBeanFactory 接口，在此基础上，还通过多个其他的接口扩展了 BeanFactory 的功能：

2:ApplicationEventPublisher：让容器拥有发布应用上下文事件的功能，包括容器启动事件、关闭事件等。实现了 ApplicationListener 事件监听接口的 Bean 可以接收到容器事件 ， 并对事件进行响应处理 。 在 ApplicationContext 抽象实现类AbstractApplicationContext 中，我们可以发现存在一个 ApplicationEventMulticaster，它负责保存所有监听器，以便在容器产生上下文事件时通知这些事件监听者。

3:MessageSource：为应用提供 i18n 国际化消息访问的功能；

4:ResourcePatternResolver ： 所 有 ApplicationContext 实现类都实现了类似于PathMatchingResourcePatternResolver 的功能，可以通过带前缀的 Ant 风格的资源文件路径装载 Spring 的配置文件。

5:LifeCycle：该接口是 Spring 2.0 加入的，该接口提供了 start()和 stop()两个方法，主要用于控制异步处理过程。在具体使用时，该接口同时被 ApplicationContext 实现及具体 Bean 实现， ApplicationContext 会将 start/stop 的信息传递给容器中所有实现了该接口的 Bean，以达到管理和控制 JMX、任务调度等目的。

ApplicationContext接口的实现

 

第一，从类结构设计上看， 围绕着是否需要Refresh容器衍生出两个抽象类：

1:GenericApplicationContext： 是初始化的时候就创建容器，往后的每次refresh都不会更改

2:AbstractRefreshableApplicationContext： AbstractRefreshableApplicationContext及子类的每次refresh都是先清除已有(如果不存在就创建)的容器，然后再重新创建；AbstractRefreshableApplicationContext及子类无法做到GenericApplicationContext混合搭配从不同源头获取bean的定义信息

第二， 从加载的源来看（比如xml,groovy,annotation等）， 衍生出众多类型的ApplicationContext, 典型比如:

1:FileSystemXmlApplicationContext： 从文件系统下的一个或多个xml配置文件中加载上下文定义，也就是说系统盘符中加载xml配置文件。

2:ClassPathXmlApplicationContext： 从类路径下的一个或多个xml配置文件中加载上下文定义，适用于xml配置的方式。

3:AnnotationConfigApplicationContext： 从一个或多个基于java的配置类中加载上下文定义，适用于java注解的方式。

4:ConfigurableApplicationContext： 扩展于 ApplicationContext，它新增加了两个主要的方法： refresh()和 close()，让 ApplicationContext 具有启动、刷新和关闭应用上下文的能力。在应用上下文关闭的情况下调用 refresh()即可启动应用上下文，在已经启动的状态下，调用 refresh()则清除缓存并重新装载配置信息，而调用close()则可关闭应用上下文。这些接口方法为容器的控制管理带来了便利，但作为开发者，我们并不需要过多关心这些方法。

没有什么是一遍两遍就懂得,没有什么是一天两天就可以实现的.愿与诸位共勉.在努力的路上有星辰我不孤单.

 如果大家喜欢我的分享的话,可以关注我的微信公众号

心有九月星辰