注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

庄庄的家

庄庄的家-网易博客

 
 
 

日志

 
 

Ioc 反转控制 依赖注入的机制  

2008-03-18 22:14:36|  分类: java试题 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

IoC就是Inverse of Control啊,就是所谓的控制反转。
即由外部传入所需的对象,而非在内部定义。好处自然就是灵活性了。当然对传入的参数的要求就是面向接口了。Java的反射机制:
通过Class类,实现动态的生成Instance(可以使用class.newInstance调用无参数的constructor或者取得特定的Constructor,再通过Constructor.newInstance。),以及动态调用Methods和设置Fields。不过对于调用特定的Method似乎也没什么很大意义,除非是已知实现了某些interface的情况下,调用指定的Method。

接口选择之惑

在实际应用中,用户有时候不知道到底是选择BeanFactory接口还是ApplicationContext接口。但是通常在构建J2EE应用时,使用ApplicationContext将是更好的选择,因为它不仅提供了BeanFactory的所有特性,同时也允许使用更多的声明方式来得到我们想要的功能。

org.springframework.beansorg.springframework.context包是Spring IoC容器的基础。BeanFactory提供的高级配置机制,使得管理任何性质的对象成为可能。ApplicationContextBeanFactory的扩展,功能得到了进一步增强,比如更易与Spring AOP集成、消息资源处理(国际化处理)、事件传递及各种不同应用层的context实现(如针对web应用的WebApplicationContext)。

简而言之,BeanFactory提供了配制框架及基本功能,而ApplicationContext则增加了更多支持企业核心内容的功能。ApplicationContext完全由BeanFactory扩展而来,因而BeanFactory所具备的能力和行为也适用于ApplicationContext

本章分为两部份,第一部份讲解BeanFactoryApplicationContext的基本原理,而第二部份则针对ApplicationContext的功能进行讲解。

3.2. 容器和bean的基本原理

在Spring中,那些组成应用的主体(backbone)及由Spring IoC容器所管理的对象被称之为bean。简单地讲,bean就是由Spring容器初始化、装配及被管理的对象,除此之外,bean就没有特别之处了(与应用中的其他对象没有什么区别)。而bean定义以及bean相互间的依赖关系将通过配置元数据来描述。

为什么使用bean?

使用'bean'这个名字而不是'组件'(component)'对象'(object)的动机源于Spring框架本身(部分原因则是相对于复杂的EJB而言的)。

3.2.1. 容器

org.springframework.beans.factory.BeanFactory是Spring IoC容器的实际代表者,IoC容器负责容纳此前所描述的bean,并对bean进行管理。

在Spring中,BeanFactory是IoC容器的核心接口。它的职责包括:实例化、定位、配置应用程序中的对象及建立这些对象间的依赖。

Spring为我们提供了许多易用的BeanFactory实现,XmlBeanFactory就是最常用的一个。该实现将以XML方式描述组成应用的对象以及对象间的依赖关系。XmlBeanFactory类将持有此XML配置元数据,并用它来构建一个完全可配置的系统或应用。

Ioc 反转控制 依赖注入的机制 - 流风 - 庄庄的家

Spring IoC 容器

3.2.1.1. 配置元数据

从上图可以看到,Spring IoC容器将读取配置元数据;并通过它对应用中各个对象进行实例化、配置以及组装。通常情况下我们使用简单直观的XML来作为配置元数据的描述格式。在XML配置元数据中我们可以对那些我们希望通过Spring IoC容器管理的bean进行定义

[Note] Note

到目前为止,基于XML的元数据是最常用到的配置元数据格式。然而,它并不是唯一的描述格式。Spring IoC容器在这一点上是完全开放的。

在本文写作时,Spring支持三种配置元数据格式:XML格式、Java属性文件格式或使用Spring公共API编程实现。由于XML元数据配置格式简单明了,因而本章采用该格式来表达Spring IoC容器的主要理念和特性。

多种资源

对IoC容器基本原理的掌握将有利于我们对Chapter 4, 资源Resource抽象机制的理解。

Spring IoC容器可以通过多种途径来加载配置元数据,比如本地文件系统、Java CLASSPATH等。

在大多数的应用程序中,并不需要用显式的代码去实例化一个或多个的Spring IoC容器实例。例如,在web应用程序中,我们只需要在web.xml中添加(大约)8 行简单的XML描述符即可(参见Section 3.8.4, “ApplicationContext在WEB应用中的实例化”)。

Spring IoC容器至少包含一个bean定义,但大多数情况下会有多个bean定义。当使用基于XML的配置元数据时,将在顶层的<beans/>元素中配置一个或多个<bean/>元素。

bean定义与应用程序中实际使用的对象一一对应。通常情况下bean的定义包括:服务层对象、数据访问层对象(DAO)、类似Struts Action的表示层对象、Hibernate SessionFactory对象、JMS Queue对象等等。项目的复杂程度将决定bean定义的多寡。

以下是一个基于XML的配置元数据的基本结构:

<?xml version="1.0" encoding="UTF-8"?><beans xmlns="http://www.springframework.org/schema/beans"       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">  <bean id="..."     <!-- collaborators and configuration for this bean go here -->  </bean>  <bean id="..."     <!-- collaborators and configuration for this bean go here -->  </bean>  <!-- more bean definitions go here... --></beans>

3.2.2. 实例化容器

Spring IoC容器的实例化非常简单,如下面的例子:

Resource resource = new FileSystemResource("beans.xml");BeanFactory factory = new XmlBeanFactory(resource);

... 或...

ClassPathResource resource = new ClassPathResource("beans.xml");BeanFactory factory = new XmlBeanFactory(resource);

... 或...

ApplicationContext context = new ClassPathXmlApplicationContext(        new String[] {"applicationContext.xml", "applicationContext-part2.xml"});// of course, an ApplicationContext is just a BeanFactoryBeanFactory factory = (BeanFactory) context;

3.2.2.1. 组成基于XML配置元数据

将XML配置文件分拆成多个部分是非常有用的。为了加载多个XML文件生成一个ApplicationContext实例,可以将文件路径作为字符串数组传给ApplicationContext构造器。而bean factory将通过调用bean defintion reader从多个文件中读取bean定义。

通常情况下,Spring团队倾向于上述做法,因为这样各个配置并不会查觉到它们与其他配置文件的组合。另外一种方法是使用一个或多个的<import/>元素来从另外一个或多个文件加载bean定义。所有的<import/>元素必须放在<bean/>元素之前以完成bean定义的导入。 让我们看个例子:

<beans><import resource="services.xml"/>    <import resource="resources/messageSource.xml"/>    <import resource="/resources/themeSource.xml"/>      <bean id="bean1"     <bean id="bean2"   </beans>

在上面的例子中,我们从3个外部文件:services.xmlmessageSource.xmlthemeSource.xml来加载bean定义。这里采用的都是相对路径,因此,此例中的services.xml一定要与导入文件放在同一目录或类路径,而messageSource.xmlthemeSource.xml的文件位置必须放在导入文件所在目录下的resources目录中。正如你所看到的那样,开头的斜杠‘/’实际上可忽略。因此不用斜杠‘/’可能会更好一点。

根据Spring XML配置文件的Schema(或DTD),被导入文件必须是完全有效的XML bean定义文件,且根节点必须为<beans/> 元素。

3.2.3. 多种bean

诚如此前所言,Spring IoC容器将管理一个或多个bean,这些bean将通过配置文件中的bean定义被创建(在XML格式中为<bean/>元素)。

在容器内部,这些bean定义由BeanDefinition 对象来表示,该定义将包含以下信息:

  • 全限定类名:这通常就是已定义bean的实际实现类。如果通过调用static factory方法来实例化bean,而不是使用常规的构造器,那么类名称实际上就是工厂类的类名。

  • bean行为的定义,即创建模式(prototype还是singleton)、自动装配模式、依赖检查模式、初始化以及销毁方法。这些定义将决定bean在容器中的行为

  • 用于创建bean实例的构造器参数及属性值。比如使用bean来定义连接池,可以通过属性或者构造参数指定连接数,以及连接池大小限制等。

  • bean之间的关系,即协作 (或者称依赖)。

上述内容直接被翻译为每个bean定义包含的一组properties。下面的表格列出了部分内容的详细链接:

除了通过bean定义来描述要创建的指定bean的属性之外,某些BeanFactory的实现也允许将那些非BeanFactory创建的、已有的用户对象注册到容器中,比如使用DefaultListableBeanFactoryregisterSingleton(..) 方法。不过大多数应用还是采用元数据定义为主。

3.2.3.1. 命名bean

bean命名约定

bean的命名采用标准的Java命名约定,即小写字母开头,首字母大写间隔的命名方式。如accountManageraccountServiceuserDaologinController,等等。

对bean采用统一的命名约定将会使配置更加简单易懂。而且在使用Spring AOP时,如果要发通知(advice)给与一组名称相关的bean时,这种简单的命名方式将会令你受益匪浅。

每个bean都有一个或多个id(或称之为标识符或名称,在术语上可以理解成一回事)。这些id在当前IoC容器中必须唯一。如果一个bean有多个id,那么其他的id在本质上将被认为是别名。

当使用基于XML的配置元数据时,将通过idname属性来指定bean标识符。id属性具有唯一性,而且是一个真正的XML ID属性,因此其他xml元素在引用该id时,可以利用XML解析器的验证功能。通常情况下最好为bean指定一个id。尽管XML规范规定了XML ID命名的有效字符,但是bean标识符的定义不受该限制,因为除了使用指定的XML字符来作为id,还可以为bean指定别名,要实现这一点可以在name属性中使用逗号、冒号或者空格将多个id分隔。

值得注意的是,为一个bean提供一个name并不是必须的,如果没有指定,那么容器将为其生成一个惟一的name。对于不指定name属性的原因我们会在后面介绍(比如内部bean就不需要)。

3.2.3.1.1. bean的别名

在对bean进行定义时,除了使用id属性来指定名称之外,为了提供多个名称,需要通过alias属性来加以指定。而所有的这些名称都指向同一个bean,在某些情况下提供别名非常有用,比如为了让应用的每一个组件能更容易的对公共组件进行引用。

然而,在定义bean时就指定所有的别名并不是总是恰当的。有时我们期望能在当前位置为那些在别处定义的bean引入别名。在XML配置文件中,可用单独的<alias/> 元素来完成bean别名的定义。如:

<alias name="fromName" alias="toName"/>

这里如果在容器中存在名为fromName的bean定义,在增加别名定义之后,也可以用toName来引用。

考虑一个更为具体的例子,组件A在XML配置文件中定义了一个名为componentA-dataSource的DataSource bean。但组件B却想在其XML文件中以componentB-dataSource的名字来引用此bean。而且在主程序MyApp的XML配置文件中,希望以myApp-dataSource的名字来引用此bean。最后容器加载三个XML文件来生成最终的ApplicationContext,在此情形下,可通过在MyApp XML文件中添加下列alias元素来实现:

<alias name="componentA-dataSource" alias="componentB-dataSource"/><alias name="componentA-dataSource" alias="myApp-dataSource" />

这样一来,每个组件及主程序就可通过唯一名字来引用同一个数据源而互不干扰。

3.2.3.2. 实例化bean

就Spring IoC容器而言,bean定义基本上描述了创建一个或多个实际bean对象的内容。当需要的时候,容器会从bean定义列表中取得一个指定的bean定义,并根据bean定义里面的配置元数据使用反射机制来创建一个实际的对象。因此这一节将讲解如何告知Spring IoC容器我们将要实例化的对象的类型以及如何实例化对象。

当采用XML描述配置元数据时,将通过<bean/>元素的class属性来指定实例化对象的类型。class 属性 (对应BeanDefinition实例的Class属性)通常是必须的(不过也有两种例外的情形,见Section 3.2.3.2.3, “使用实例工厂方法实例化”Section 3.6, “bean定义的继承”)。class属性主要有两种用途:在大多数情况下,容器将直接通过反射调用指定类的构造器来创建bean(这有点等类似于在Java代码中使用new操作符);在极少数情况下,容器将调用类的静态工厂方法来创建bean实例,class属性将用来指定实际具有静态工厂方法的类(至于调用静态工厂方法创建的对象类型是当前class还是其他的class则无关紧要)。

3.2.3.2.1. 用构造器来实例化

当采用构造器来创建bean实例时,Spring对class并没有特殊的要求,我们通常使用的class都适用。也就是说,被创建的类并不需要实现任何特定的接口,或以特定的方式编码,只要指定bean的class属性即可。不过根据所采用的IoC类型,class可能需要一个默认的空构造器。

此外,IoC容器不仅限于管理JavaBean,它可以管理任意的类。不过大多数使用Spring的人喜欢使用实际的JavaBean(具有默认的(无参)构造器及setter和getter方法),但在容器中使用非bean形式(non-bean style)的类也是可以的。比如遗留系统中的连接池,很显然它与JavaBean规范不符,但Spring也能管理它。

当使用基于XML的元数据配置文件,可以这样来指定bean类:

<bean id="exampleBean"  name="anotherExample"  <
3.2.3.2.2. 使用 静态工厂方法实例化

当采用静态工厂方法创建bean时,除了需要指定class属性外,还需要通过factory-method属性来指定创建bean实例的工厂方法。Spring将调用此方法(其可选参数接下来介绍)返回实例对象,就此而言,跟通过普通构造器创建类实例没什么两样。

下面的bean定义展示了如何通过工厂方法来创建bean实例。注意,此定义并未指定返回对象的类型,仅指定该类包含的工厂方法。在此例中, createInstance()必须是一个static方法。

<bean id="exampleBean"            factory-method="createInstance"/>

给工厂方法指定参数以及为bean实例设置属性将在随后的部份中谈及。

3.2.3.2.3. 使用实例工厂方法实例化

使用静态工厂方法实例化类似,用来进行实例化的实例工厂方法位于另外一个已有的bean中,容器将调用该bean的工厂方法来创建一个新的bean实例

为使用此机制,class属性必须为空,而factory-bean属性必须指定为当前(或其祖先)容器中包含工厂方法的bean的名称,而该工厂bean的工厂方法本身必须通过factory-method属性来设定(参看以下的例子)。

<!-- the factory bean, which contains a method called createInstance() --><bean id="myFactoryBean"   ...</bean>  <!-- the bean to be created via the factory bean --><bean id="exampleBean"      factory-bean="myFactoryBean"      factory-method="createInstance"/>

虽然设置bean属性的机制仍然在这里被提及,但隐式的做法是由工厂bean自己来管理以及通过依赖注入(DI)来进行配置。

3.2.4. 使用容器

从本质上讲,BeanFactory仅仅只是一个维护bean定义以及相互依赖关系的高级工厂接口。通过BeanFactory我们可以访问bean定义。下面的例子创建了一个bean工厂,此工厂将从xml文件中读取bean定义:

InputStream is = new FileInputStream("beans.xml");BeanFactory factory = new XmlBeanFactory(is);

基本上就这些了,接着使用getBean(String)方法就可以取得bean的实例;BeanFactory提供的方法极其简单。它仅提供了六种方法供客户代码调用:

  • boolean containsBean(String):如果BeanFactory包含给定名称的bean定义(或bean实例),则返回true

  • Object getBean(String):返回以给定名字注册的bean实例。根据bean的配置情况,如果为singleton模式将返回一个共享的实例,否则将返回一个新建的实例。如果没有找到指定的bean,该方法可能会抛出BeansException异常(实际上将抛出NoSuchBeanDefinitionException异常),在对bean进行实例化和预处理时也可能抛出异常

  • Object getBean(String, Class):返回以给定名称注册的bean实例,并转换为给定class类型的实例,如果转换失败,相应的异常(BeanNotOfRequiredTypeException)将被抛出。上面的getBean(String)方法也适用该规则。

  • Class getType(String name):返回给定名称的bean的Class。如果没有找到指定的bean实例,则抛出NoSuchBeanDefinitionException异常。

  • boolean isSingleton(String):判断给定名称的bean定义(或bean实例)是否为singleton模式(singleton将在bean的作用域中讨论),如果bean没找到,则抛出NoSuchBeanDefinitionException异常。

  • String[] getAliases(String):返回给定bean名称的所有别名。

3.3. 依赖

典型的企业应用不会只由单一的对象(或bean)组成。毫无疑问,即使最简单的系统也需要多个对象一起来满足最终用户的需求。接下来的的内容除了阐述如何单独定义一系列bean外,还将描述如何让这些bean对象一起协同工作来实现一个完整的真实应用。

3.3.1. 注入依赖

依赖注入(DI)背后的基本原理是对象之间的依赖关系(即一起工作的其它对象)只会通过以下几种方式来实现:构造器的参数、工厂方法的参数,或给由构造函数或者工厂方法创建的对象设置属性。因此,容器的工作就是创建bean时注入那些依赖关系。相对于由bean自己来控制其实例化、直接在构造器中指定依赖关系或者类似服务定位器(Service Locator)模式这3种自主控制依赖关系注入的方法来说,控制从根本上发生了倒转,这也正是控制反转(Inversion of Control, IoC) 名字的由来。

应用DI原则后,代码将更加清晰。而且当bean自己不再担心对象之间的依赖关系(以及在何时何地指定这种依赖关系和依赖的实际类是什么)之后,实现更高层次的松耦合将易如反掌。

诚如此前的章节所述,DI主要有两种注入方式,即Setter注入构造器注入

3.3.1.1. Setter注入

通过调用无参构造器或无参static工厂方法实例化bean之后,调用该bean的setter方法,即可实现基于setter的DI。

下面的例子将展示使用setter注入依赖。注意,这个类并没有什么特别之处,它就是普通的Java类。

public class SimpleMovieLister {      // the SimpleMovieLister has a dependency on the MovieFinder    private MovieFinder movieFinder;      // a setter method so that the Spring container can 'inject' a MovieFinder    public void setMoveFinder(MovieFinder movieFinder) {        this.movieFinder = movieFinder;    }        // business logic that actually 'uses' the injected MovieFinder is omitted...}

3.3.1.2. 构造器注入

基于构造器的DI通过调用带参数的构造器来实现,每个参数代表着一个协作者。此外,还可通过给静态工厂方法传参数来构造bean。接下来的介绍将认为给构造器传参与给静态工厂方法传参是类似的。

下面的展示了只能使用构造器参数来注入依赖关系的例子。再次提醒,这个类并没有什么特别之处

public class SimpleMovieLister {      // the SimpleMovieLister has a dependency on the MovieFinder    private MovieFinder movieFinder;      // a constructor so that the Spring container can 'inject' a  MovieFinder    public SimpleMovieLister(MovieFinder movieFinder) {        this.movieFinder = movieFinder;    }        // business logic that actually 'uses' the injected MovieFinder is omitted...}

如何在构造器注入和Setter注入之间进行选择?

由于大量的构造器参数可能使程序变得笨拙,特别是当某些属性是可选的时候。因此通常情况下,Spring开发团队提倡使用setter注入。而且setter DI在以后的某个时候还可将实例重新配置(或重新注入)(JMX MBean就是一个很好的例子)。

尽管如此,构造器注入因为某些原因还是受到了一些人的青睐。一次性将所有依赖注入的做法意味着,在未完全初始化的状态下,此对象不会返回给客户代码(或被调用),此外对象也不可能再次被重新配置(或重新注入)。

对于注入类型的选择并没硬性的规定。只要能适合你的应用,无论使用何种类型的DI都可以。对于那些没有源代码的第三方类,或者没有提供setter方法的遗留代码,我们则别无选择--构造器注入将是你唯一的选择。

BeanFactory对于它所管理的bean提供两种注入依赖方式(实际上它也支持同时使用构造器注入和Setter方式注入依赖)。需要注入的依赖将保存在BeanDefinition中,它能根据指定的PropertyEditor实现将属性从一种格式转换成另外一种格式。然而,大部份的Spring用户并不需要直接以编程的方式处理这些类,而是采用XML的方式来进行定义,在内部这些定义将被转换成相应类的实例,并最终得到一个Spring IoC容器实例。

处理bean依赖关系通常按以下步骤进行:

  1. 根据定义bean的配置(文件)创建并初始化BeanFactory实例(大部份的Spring用户使用支持XML格式配置文件的BeanFactoryApplicationContext实现)。

  2. 每个bean的依赖将以属性、构造器参数、或静态工厂方法参数的形式出现。当这些bean被实际创建时,这些依赖也将会提供给该bean。

  3. 每个属性或构造器参数既可以是一个实际的值,也可以是对该容器中另一个bean的引用。

  4. 每个指定的属性或构造器参数值必须能够被转换成属性或构造参数所需的类型。默认情况下,Spring会能够以String类型提供值转换成各种内置类型,比如intlongStringboolean等。

需要强调的一点就是,Spring会在容器被创建时验证容器中每个bean的配置,包括验证那些bean所引用的属性是否指向一个有效的bean(即被引用的bean也在容器中被定义)。然而,在bean被实际创建之前,bean的属性并不会被设置。对于那些singleton类型和被设置为提前实例化的bean(比如ApplicationContext中的singleton bean)而言,bean实例将与容器同时被创建。而另外一些bean则会在需要的时候被创建,伴随着bean被实际创建,作为该bean的依赖bean以及依赖bean的依赖bean(依此类推)也将被创建和分配。

循环依赖

当你主要使用构造器注入的方式配置bean时,很有可能会产生循环依赖的情况。

比如说,一个类A,需要通过构造器注入类B,而类B又需要通过构造器注入类A。如果为类A和B配置的bean被互相注入的话,那么Spring IoC容器将在运行时检测出循环引用,并抛出 BeanCurrentlyInCreationException异常。

对于此问题,一个可能的解决方法就是修改源代码,将构造器注入改为setter注入。另一个解决方法就是完全放弃使用构造器注入,只使用setter注入。

通常情况下,你可以信赖Spring,它会在容器加载时发现配置错误(比如对无效bean的引用以及循环依赖)。Spring会在bean创建的时才去设置属性和依赖关系(只在需要时创建所依赖的其他对象)。Spring容器被正确加载之后,当获取一个bean实例时,如果在创建bean或者设置依赖时出现问题,那么将抛出一个异常。因缺少或设置了一个无效属性而导致抛出一个异常的情况的确是存在的。因为一些配置问题而导致潜在的可见性被延迟,所以在默认情况下,ApplicationContext实现中的bean采用提前实例化的singleton模式。在实际需要之前创建这些bean将带来时间与内存的开销。而这样做的好处就是ApplicationContext被加载的时候可以尽早的发现一些配置的问题。不过用户也可以根据需要采用延迟实例化来替代默认的singleton模式。

最后,我们还要提到的一点就是,当协作bean被注入到依赖bean时,协作bean必须在依赖bean之前完全配置好。例如bean A对bean B存在依赖关系,那么Spring IoC容器在调用bean A的setter方法之前,bean B必须被完全配置,这里所谓完全配置的意思就是bean将被实例化(如果不是采用提前实例化的singleton模式),相关的依赖也将被设置好,而且所有相关的lifecycle方法(如IntializingBean的init方法以及callback方法)也将被调用

  评论这张
 
阅读(716)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017