Spring IOC容器

4.1 Spring IoC容器和bean的介绍

  IoC也被称为是依赖注入(DI)。先构造对象,设置属性等,然后容器在bean的时候注入那些依赖,控制反转(IoC)。

  Bean本身控制实例化或直接地使用类的构造来定位它的依赖,或者是如服务定位器模式的机制。

  org.springframework.beans和org.springframework.context包是Spring Framework的IoC容器的基础。BeanFactory接口提供高级的配置机制,可以管理任意类型的对象。ApplicationContext是BeanFactory的子接口。它添加了和Spring的AOP特性很简便的整合;消息资源处理(用于国际化i18n),事件发布;应用层特定的上下文,比如用于Web应用程序的WebApplicationContext。
  BeanFactory提供了配置框架和基本功能,而ApplicationContext添加了更多企业级开发特定的功能。ApplicationContext是BeanFactory完整的超集。
  一个Bean就是一个实例化并组装的对象,由Spring的IoC容器来管理。否则,bean就是应用程序中众多对象之一。Bean和它们之间的依赖,反射出由容器使用的配置元数据。

4.2 容器概述

  ApplicationContext接口代表了Spring的IoC容器,负责实例化,配置和装配上述的bean。

  容器获得指示来实例化某对象,配置并装配,这都是通过读取配置元数据实现的。配置元数据在XML中,Java注解或Java代码中来表示。
  在独立的应用程序中,通常是来创建ClassPathXmlApplicationContext或FileSystemXmlApplicationContext的实例。XML是定义配置元数据的传统格式,你可以指示容器使用Java的注解或是代码作为元数据的格式,提供少量的XML配置声明来开启对这些额外的元数据格式的支持。
  在很多应用场景中,明确的用户代码不需要实例化一个或者多个Spring IoC容器的实例。在ApplicationContext被创建和实例化后,就得到了一个完全配置的可执行系统或程序。

 

4.2.1 配置元数据

4.2.2 实例化容器

4.2.3 使用容器

  ApplicationContext的getBean()其实是调用的FactoryBean的getObject()

4.3 Bean概述

  在容器本身,这些bean代表了BeanDefinition对象

4.3.1 命名bean

4.3.2 实例化bean

  使用构造方法实例化

  使用静态工厂方法来实例化

  使用实例工厂方法来实例化

4.8 容器扩展点

4.8.1 使用BeanPostProcessor来自定义bean

  BeanPostProcessor接口定义了你可以提供实现自己的(或覆盖容器默认的)实例逻辑,依赖解析逻辑等的回调方法。在Spring容器完成实例化,配置和初始化bean之后实现一些自定义逻辑。
  如果有多个BeanPostProcessor实例,还可以通过设置order属性来控制这些BeanPostProcessor执行的顺序。但BeanPostProcessor必须实现了Ordered接口。
注意

  1.   BeanPostProcessor操作bean(对象)实例;也就是说,Spring的IoC容器实例化bean的实例,之后BeanPostProcessor来做它们要做的事情。
  2.   如果你在一个容器中定义了BeanPostProcessor,那么它仅仅会在那个容器中后处理bean。换句话说,一个容器中定义的bean不会被另外一个容器中定义的BeanPostProcessor来进行后处理,即便是两个容器都是相同继承链上的一部分。

  ApplicationContext会自动检测任意实现了BeanPostProcessor接口的bean定义的配置元数据。ApplicationContext注册这些bean作为后处理器,那么它们可以在bean创建之后被调用。Bean的后处理器可以在容器中部署,就像其它bean那样。
  BeanPostProcessor和AOP自动代理
  实现了BeanPostProcessor接口的类是特殊的,会被容器不同对待。所有它们参照的BeanPostProcessor和bean会在启动时被实例化,作为ApplicationContext启动阶段特殊的一部分。接下来,所有的BeanPostProcessor以排序的方式注册并应用于容器中的其它bean。因为AOP自动代理作为BeanPostProcessor本身的实现,它们为自动代理资格的直接引用的既不是BeanPostProcessor也不是bean,因此没有织入它们的方面。
对于这样的bean,你应该看到一个信息级的日志消息:“Bean foo没有由所有BeanPostProcessor接口处理的资格(比如:没有自动代理的资格)”。

4.8.2 使用BeanFactoryPostProcessor自定义配置元数据

BeanFactoryPostProcessor操作bean的配置元数据;也就是说Spring的IoC容器允许BeanFactoryPostProcessor来读取配置元数据并在容器实例BeanFactoryPostProcessor以外的任何bean之前可以修改它。
可以配置多个BeanFactoryPostProcessor,也可以通过order属性来控制这些BeanFactoryPostProcessor执行的顺序。仅当BeanFactoryPostProcessor实现Ordered接口时才能设置这个属性。
注意

  1.   如果你想改变真实的bean实例(也就是说,从配置元数据中创建的对象),那么你需要使用BeanPostProcessor(在上面4.8.1节,“使用BeanPostProcessor来自定义bean”中描述)来代替。在BeanFactoryPostProcessor(比如使用BeanFactory.getBean())中来使用这些bean的实例虽然在技术上是可行的,但这么来做会引起bean过早实例化,违反标准的容器生命周期。这也会引发一些副作用,比如绕过bean的后处理。
  2. 而且,BeanFactoryPostProcessor的范围也是对每一个容器来说的。如果你使用了容器的继承的话,这就是唯一相关的点了。如果你在一个容器中定义了BeanFactoryPostProcessor,那么它只会用于在那个容器中的bean。一个容器中Bean的定义不会被另外一个容器中的BeanFactoryPostProcessor后处理,即便两个容器都是相同继承关系的一部分。

  当在ApplicationContext中声明时,bean工厂后处理器会自动被执行,这就可以对定义在容器中的配置元数据进行修改。
  ApplicationContext会自动检测任意部署其中,且实现了BeanFactoryPostProcessor接口的bean。在适当的时间,它用这些bean作为bean工厂后处理器。你可以部署这些后处理器bean作为你想用的任意其它的bean。
注意
  和BeanPostProcessor一样,通常你不会想配置BeanFactoryPostProcessor来进行延迟初始化。如果没有其它bean引用Bean(Factory)PostProcessor,那么后处理器就不会被初始化了。因此,标记它为延迟初始化就会被忽略,即便你在<beans/>元素声明中设置default-lazy-init属性为true,那么Bean(Factory)PostProcessor也会正常被初始化。

posted @ 2013-04-19 17:02  跳刀的兔子  阅读(635)  评论(0编辑  收藏  举报