Spring核心——Bean的依赖注入

全文共 2414 个字

依赖注入

设计模式与IoC这篇文章中,介绍了Spring基础的三大支柱的两项内容——IoC、Bean。本篇将继续围绕着Bean的创建时的注入方式来介绍Spring的核心思想与设计模式。

天底下所有面向对象的语言都不可能只用一个类来解决问题,即使是最简单的应用程序都存在类与类之间的依存关系。如下面这个人人都理解的组合例子:

class Foo{
   private Other other;
   public Foo(){
      other = new Other();
   }
}

class Other{}

在设计模式上关于类的组合与继承的适用性不属于本篇的讨论范围,但是从Spring框架非侵入式的设计思路来看,组合才是使用Spring的正确姿势。

官方将这种组合的关系叫做“依赖注入(DI——Dependency injection)”。从名字上来看这也是一种依托Ioc容器很自然的实现方式——所有的Bean都放置在容器中,然后通过一些配置来告诉容器bean与bean之间的依存关系。一个类除了在内部块中通过new关键字实现一个组合关系,也可以通过构造方法传参或接口方法设置。

由于IoC容器不可能去修改一个类内部的代码,所以类与类的组合方式通过构造方法(Constructor)和set方法(Setter)来实现。此外,Ioc可以根据接口(interface)来注入对应的实现类(class extands interface),所以从设计模式的角度来说,依赖注入的方式很好的规避了标准组合模式中new关键字违反依赖倒置原则的问题。

构造方法注入

直接通过构造方法注入组合数据。

class:

package x.y;

public class A {
    private B b;
    private C c;
    public Foo(B b, C c) {
       this.b = b;
       this.c = c;
    }
}
public class B {}
public class C {}

xml:

<beans>
    <bean id="a" class="x.y.A">
        <constructor-arg ref="b"/>
        <constructor-arg ref="c"/>
    </bean>

    <bean id="b" class="x.y.B"/>

    <bean id="c" class="x.y.C"/>
</beans>

如果是源生类型的参数,可以通过指定类型来注入数据:

package x.y;

public class A {
    private int b;
    private String c;
    public Foo(int b, String c) {
       this.b = b;
       this.c = c;
    }
}
<bean id="a" class="x.y.A">
    <constructor-arg type="int" value="1"/>
    <constructor-arg type="java.lang.String" value="42"/>
</bean>

也可以通过索引的方式:

<bean id="a" class="x.y.A">
    <constructor-arg index="0" value="1"/>
    <constructor-arg index="1" value="42"/>
</bean>

配合@ConstructorProperties注解,还可以直接使用名称来注入:

package x.y;

public class A {
    private int b;
    private String c;
    @ConstructorProperties({"b", "c"})
    public Foo(int b, String c) {
       this.b = b;
       this.c = c;
    }
}
<bean id="exampleBean" class="examples.ExampleBean">
    <constructor-arg name="b" value="1"/>
    <constructor-arg name="c" value="42"/>
</bean>

在Debug模式下不用这个注解也可以实现按名字注入,但是千万别这样做。

Set方法注入

package x.y;

public class A {
    private B b;
    private C c;
    private String value;
    public void setA(A a){this.a = a;}
    public void setB(B b){this.b = b;}
    public void setB(String value){this.value = value;}
}
public class B {}
public class C {}
<bean id="a" class="x.y.A">
    <property name="b" ref="b"/>
    <property name="c" ref="c"/>
    <property name="value" value="1"/>
</bean>
<bean id="b" class="x.y.B"/>
<bean id="c" class="x.y.C"/>

使用 Constructor还是Setter?

2种注入方法在使用的过程中我们应该如何选取呢?Spring官方给出的答案是如果注入的数据或bean是一个“必要依赖”那么使用构造方法注入,如果属于配置性的非必须数据,使用Set方法注入。但是在实际应用时,会发现绝大部分注入方式都是通过Setter实现的,包括一些很流行的开源工具,例如下面的druid:

<bean id="ds" class="com.mchange.v2.c3p0.ComboPooledDataSource">
     <property name="driverClass" value="com.mysql.jdbc.Driver"/>
     <property name="jdbcUrl" value="jdbc:mysql://localhost:3306/c3p0jdbctemplate"/>
     <property name="user" value="admin"/>
     <property name="password" value="123456"/>
</bean>

话说你不提供账户和密码能链接到数据库吗?这算必要依赖还是配置性依赖?所以也不用死守这些规则。下面是一些关键性的建议:

  1. 数据配置类使用constructor注入的方法来实现,因为这样可以将bean设置为一个不可变对象(immutable objects)。这样结合单例模式能够很好实现享元模式共享数据,结合原型模式可以创建“浅对比”对象(变更则替换)。
  2. 如果构造函数要传入的参数太多,证明你的类要完成的责任太多,这个时候用Setter当然比较合理,但是建议回头去看看类当中是不是有可以拆分的功能。
  3. Setter注入主要用于可选的依赖关系,如果没有设置值,类应该提供默认值。所以Setter方法应该检查传入值的有效性(not null、not blank等)。
  4. 如果出现了循环依赖,其实可以通过一个bean使用setter注入另外一个bean使用constructor注入来解决,不过最好检查一下代码为什么会循环,这是设计模式上的大忌。
  5. 最有一个建议最重要。如果用第三方类,别人给什么你只能用什么,没得选。

注入参数

在XML配置中,用来设定注入方式和注入数据的XML标签很多,详细内容就不一一复述了,常规用法可以到官网 Dependencies and configuration in detail  一节了解。这里仅仅说明一些要点:

  1. 父子Bean。Ioc容器提供Bean的父子关系配置。父子关系Bean可以进行数据合并,但是很少看见什么地方有实际应用。
  2. <idref>标签和<ref>标签的差异:1)前者只能通过id引入,后者可以通过id或name引入;2)前者可以直接用value属性替换,但是value属性的效率会差很多;3)前者只能适用与当前配置文件或当前容器,后者可以引入任何位置的内容。
  3. 当需要设置一个null值时,用<null>标签代替value=""。在执行代码时直接传入一个null。

自动装配

这里所说的自动装配是通过<bean>上的autowire属性实现的功能,与@Autowired注解并不是一回事,但是他的一些参数会影像@Autowired注解的行为。

在有@Autowired注解的情况下,autowire属性现在用得很少。基本上他实现的结果和@Autowired差不多,就是让Ioc容器根据bean的类型或者bean名称等自动将容器中其他能对应得上的bean注入到对于的构造方法或者set方法中。详情了解 Autowiring collaborators

方法注入

如果每一个Bean都是单例模式,那么我们通过常规的XML配置引用的手段就可以实现所有的依赖组合关系。但是每个bean都有不同的生命周期,常规配置方法很难实现某些应用不同生命周期bean的依赖关系。

第一种方式是通过继承 ApplicationContextAware 类,继承后可以直接使用 applicationContext 的 getBean 接口来获取任何一个 bean。

package x.y;
import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;

public class BeanManagerFoo implements ApplicationContextAware {

    private ApplicationContext applicationContext;

    public <T> T getBean(Class<T> type){
		return applicationContext.getBean(type);
	}

    public Object getBean(String id){
		return springContext.getBean(id);
	}

    public void setApplicationContext(
            ApplicationContext applicationContext) throws BeansException {
        this.applicationContext = applicationContext;
    }
}

第二种方法是使用Lookup Method。

Lookup Method的实现思路是使用CGLIB生成了动态代理类并放置到Ioc中代替源生的类。看下面的例子。

首先实现我们的抽象类,抽象的要求至少有一个抽象方法:

package x.y;

public abstract class A {
    public String getName() {
        B b = this.createB();
        return b.getName();
    }

    protected abstract B createB();
}

public class B {
    private String name = "B class";
    public String getName(){
        return this.name;
    }
}

然后通过<lookup-method>标签来指定获取bean的方式:

<bean id="b" class="x.y.B" scope="prototype" />

<bean id="a" class="x.y.A">
    <lookup-method name="createB" bean="b"/>
</bean>

现在,在调用A.getName方法时都会创建一个新的B类实例。需要注意scope属性,如果修改为singleton则每次都获取同一个B实例。

使用动态代理由于是字节码级别的变换,所有有很多限制需要注意:方法和类都不能用fina关键字;测试用例需要自己实现代理模式,否则抽象类没有实现;

第三种方法是使用委派模式,即我们执行A.compute方法时,实际执行的是被委派的B.reimplement方法。

先定义2个基础类——Origin、Replace:

package x.y
public class Origin {
    public int compute(int in1, int in2) {
        return in1+in2;
    }
}

public class Replace {
    public int reimplement(Object o, Method m, Object[] args) {
        int in1 = (int)args[0];
        int in2 = (int)args[1];
        return in1+in2;
    }
}

然后定义Spring配置:

<bean id="origin" class="x.y.Origin">
    <replaced-method name="compute" replacer="replace">
        <arg-type>int</arg-type>
        <arg-type>int</arg-type>
    </replaced-method>
</bean>

<bean id="replace" class="x.y.Replace"/>

这个时候,在任何时候执行“origin”这个bean的compute方法,实际上都是执行的Replace::reimplement方法。

上面<arg-type/>的参数用全称或简写都可以,例如java.lang.String,使用String,Str都是指向这个类型。

使用委派模式的好处是限制少、灵活,并且不会用到CGLIB这种重量级工具。但是委派之后委派方法的真实参数和被委派方法的参数完全不一样,开发时需要时时刻刻紧跟委派类的结构来修改代码。一旦委派类发生任何修改而没有相应的调整被委派类,可能会出现意想不到的问题。