配置类中的注入或方法调用

时间:2016-06-11 19:18:32

标签: java spring

在以下示例中,resultresult2 bean定义之间存在任何不同:

import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Scope;

@Configuration
public class Application {

    @Bean
    public Integer data1() {
        return 42;
    }

    @Bean
    public Integer data2() {
        return 7;
    }

    @Bean
    public Integer result(
            @Qualifier("data1") Integer a,
            @Qualifier("data2") Integer b) {
        return a + b;
    }

    @Bean
    public Integer result2() {
        return data1() + data2();
    }


    public static void main(final String... args) {
        final ApplicationContext context = new AnnotationConfigApplicationContext(Application.class);
        System.out.println(context.getBean("result"));
        System.out.println(context.getBean("result2"));
    }
}
  • 有相关的最佳做法吗?
  • 有什么缺点吗?

1 个答案:

答案 0 :(得分:1)

第一个问题:有什么不同吗?

是的,result版本将获得两个依赖于依赖注入的bean,并遵循有关这些bean范围的所有规则。 result2版本本身调用两个工厂方法,并没有利用依赖注入。

第二和第三个问题:是否有任何最佳做法或缺点?

实际上让spring注入依赖项的第一个版本受益于spring依赖注入带来的所有优势。您可以指定范围并覆盖要在其他上下文中注入的bean的规范。

另一个版本只会对两个工厂方法本身进行硬编码调用,这意味着工厂方法本身不能注入任何依赖项,也不会考虑范围等任何注释。

我的建议是使用版本一,它遵循依赖注入范例。否则,至少应将两个工厂方法视为常规方法并删除弹簧注释,以免欺骗任何弹簧管理bean生命周期的代码读者。

想象一个非平凡的例子,其中data1data2正在创建由其他几个bean使用的复杂bean,并且您可能希望根据上下文更改实际实例,例如unit测试,测试/舞台环境或制作......