Spring Framework Core(1)-The Ioc Container(4)

1 IoC 容器

1.4 依赖

1.4.6 方法注入

在大多数应用程序场景中，容器中的大多数bean都是单例的。当一个单例bean需要与另一个单例bean协作，或者一个非单例bean需要与另一个非单例bean协作时，通常通过将一个bean定义为另一个bean的属性来处理依赖性。当bean的生命周期不同时，就会出现问题。假设单例bean A需要使用非单例(原型)bean B，可能是在A的每个方法调用上。容器只创建一次单例bean，因此只得到一次设置属性的机会。容器不能实现每当Bean A 需要新的Bean B实例时，都能向Bean A 提供一个Bean B实例。

解决的办法是放弃一些控制反转。您可以通过实现applicationcontextAware接口，并在每次bean A需要时调用容器的getBean(“B”)来请求(通常是一个新的)bean B实例，从而使bean A知道容器。下面的例子展示了这种方法:

// a class that uses a stateful Command-style class to perform some processing
package fiona.apple;

// Spring-API imports
import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;

public class CommandManager implements ApplicationContextAware {

    private ApplicationContext applicationContext;

    public Object process(Map commandState) {
        // grab a new instance of the appropriate Command
        Command command = createCommand();
        // set the state on the (hopefully brand new) Command instance
        command.setState(commandState);
        return command.execute();
    }

    protected Command createCommand() {
        // notice the Spring API dependency!
        return this.applicationContext.getBean("command", Command.class);
    }

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

但是上面的方法是不可取的，因为业务代码知道Spring框架并与之耦合。方法注入是Spring IoC容器的一个比较高级的特性，它允许您干净地处理这个用例。

您可以在这篇博客中了解更多关于方法注入的动机。

查找方法注入

查找方法注入是容器覆盖容器管理bean上的方法并返回容器中另一个命名bean的查找结果的能力。查找通常涉及到一个prototype bean，如前一节描述的场景所示。Spring框架通过使用来自CGLIB库的字节码生成来动态生成覆盖该方法的子类，从而实现了这种方法注入。

• 要使这个动态子类工作，Spring bean容器子类的类不能是final，要覆盖的方法也不能是final。
• 对具有抽象方法的类进行单元测试需要您自己对该类进行子类化，并提供抽象方法的存根实现。
• 组件扫描也需要具体的方法，这需要具体的类来获取。
• 进一步的关键限制是，查找方法不能与工厂方法一起工作，特别是不能与配置类中的@Bean方法一起工作，因为在这种情况下，容器不负责创建实例，因此不能动态地创建运行时生成的子类。

在前面代码片段中的CommandManager类的情况下，Spring容器动态地覆盖createCommand()方法的实现。CommandManager类没有任何Spring依赖项，如重新处理的示例所示：

package fiona.apple;
// no more Spring imports!

public abstract class CommandManager {

    public Object process(Object commandState) {
        // grab a new instance of the appropriate Command interface
        Command command = createCommand();
        // set the state on the (hopefully brand new) Command instance
        command.setState(commandState);
        return command.execute();
    }

    // okay... but where is the implementation of this method?
    protected abstract Command createCommand();
}

在包含要注入的方法的client类中(本例中的CommandManager)，要注入的方法需要以下形式的签名:

<public|protected> [abstract] <return-type> theMethodName(no-arguments);

如果方法是抽象的，则动态生成的子类实现该方法。否则，动态生成的子类将覆盖在原始类中定义的具体方法。考虑下面的例子:

<!-- a stateful bean deployed as a prototype (non-singleton) -->
<bean id="myCommand" class="fiona.apple.AsyncCommand" scope="prototype">
    <!-- inject dependencies here as required -->
</bean>

<!-- commandProcessor uses statefulCommandHelper -->
<bean id="commandManager" class="fiona.apple.CommandManager">
    <lookup-method name="createCommand" bean="myCommand"/>
</bean>

标识为commandManager的bean在需要myCommand bean的新实例时调用自己的createCommand()方法。如果实际需要的话，您必须小心地将myCommand bean部署为 prototype 。如果它是singleton,的，那么每次都会返回相同的myCommand bean实例。

或者，在基于注释的组件模型中，可以通过@Lookup注释声明查找方法，如下面的示例所示:

public abstract class CommandManager {

    public Object process(Object commandState) {
        Command command = createCommand();
        command.setState(commandState);
        return command.execute();
    }

    @Lookup("myCommand")
    protected abstract Command createCommand();
}

或者，更具体地说，您可以依赖于根据声明的查找方法返回类型解析目标bean:

public abstract class CommandManager {

    public Object process(Object commandState) {
        MyCommand command = createCommand();
        command.setState(commandState);
        return command.execute();
    }

    @Lookup
    protected abstract MyCommand createCommand();
}

请注意，您通常应该使用具体的存根实现来声明此类带注解的查找方法，以便使它们与Spring的组件扫描规则兼容，其中抽象类在缺省情况下被忽略。此限制不适用于显式注册或显式导入的bean类。

访问范围不同的目标bean的另一种方法是ObjectFactory / Provider注入点。请参考Scoped Beans as Dependencies。

ServiceLocatorFactoryBean(在org.springframework.beans.factory.config中)也是很有用的

任意的方法替换

与查找方法注入相比，一种不太有用的方法注入形式是能够用另一种方法实现替换托管bean中的任意方法。您可以安全地跳过本节的其余部分，直到您真正需要此功能为止。

对于基于xml的配置元数据，您可以使用replace-method元素将已部署bean的现有方法实现替换为其他方法实现。考虑下面的类，它有一个我们想要覆盖的叫做computeValue的方法:

public class MyValueCalculator {

    public String computeValue(String input) {
        // some real code...
    }

    // some other methods...
}

实现org.springframe.bean.factory.support的类。MethodReplacer接口提供了新的方法定义，如下例所示:

/**
 * meant to be used to override the existing computeValue(String)
 * implementation in MyValueCalculator
 */
public class ReplacementComputeValue implements MethodReplacer {

    public Object reimplement(Object o, Method m, Object[] args) throws Throwable {
        // get the input value, work with it, and return a computed result
        String input = (String) args[0];
        ...
        return ...;
    }
}

部署原始类并指定方法覆盖的bean定义类似于以下示例:

<bean id="myValueCalculator" class="x.y.z.MyValueCalculator">
    <!-- arbitrary method replacement -->
    <replaced-method name="computeValue" replacer="replacementComputeValue">
        <arg-type>String</arg-type>
    </replaced-method>
</bean>

<bean id="replacementComputeValue" class="a.b.c.ReplacementComputeValue"/>

您可以在< replacedmethod />元素中使用一个或多个< argtype />元素来指示被覆盖方法的方法签名。只有在方法重载且类中存在多个变量时，才需要对参数进行签名。
为了方便起见，参数的类型字符串可以是完全限定类型名称的子字符串。例如，以下所有匹配java.lang.String:

java.lang.String
String
Str

因为参数的数量通常足以区分每种可能的选择，所以这个快捷方式可以节省大量的输入，因为它允许您只输入与参数类型匹配的最短字符串。