干净的代码 - @Autowired 应该应用在哪里？

我将从一个简单的例子开始。你有一个 Spring boot 应用程序运行CommandLineRunner初始化时的类。

// MyCommandLineRunner.java
public class MyCommandLineRunner implements CommandLineRunner {
    private final Log logger = LogFactory.getLog(getClass());
    @Autowired //IntelliJ Warning
    private DataSource ds;
    @Override
    public void run(String... args) throws Exception {
        logger.info("DataSource: " + ds.toString());
    }
}
// Application.java
@SpringBootApplication
public class Application {
    public static void main(String... args) {
        SpringApplication.run(Application.class, args); 
    }
    @Bean
    public MyCommandLineRunner schedulerRunner() {
        return new MyCommandLineRunner();
    }
}

现在，就像这样，这行得通，一切都OK了。然而，IntelliJ 报告了一个警告，其中@Autowired位于（我在评论中标记了位置）

Spring团队推荐：始终在 bean 中使用基于构造函数的依赖注入。始终对强制依赖项使用断言。

现在，如果我遵循这个，我就有了一个基于构造函数的依赖注入

@Autowired
public MyCommandLineRunner(DataSource ds) { ... }

这也意味着我必须编辑Application.java同样，因为构造函数需要一个参数。在Application.java如果我尝试使用 setter 注入，我会收到相同的警告。如果我也重构它，我认为最终会得到一些令人讨厌的代码。

// MyCommandLineRunner.java
public class MyCommandLineRunner implements CommandLineRunner {
    private final Log logger = LogFactory.getLog(getClass());
    private DataSource ds;
    @Autowired // Note that this line is practically useless now, since we're getting this value as a parameter from Application.java anyway.
    public MyCommandLineRunner(DataSource ds) { this.ds = ds; }
    @Override
    public void run(String... args) throws Exception {
        logger.info("DataSource: " + ds.toString());
    }
}
// Application.java
@SpringBootApplication
public class Application {
    private DataSource ds;
    @Autowired
    public Application(DataSource ds) { this.ds = ds; }
    public static void main(String... args) {
        SpringApplication.run(Application.class, args); 
    }
    @Bean
    public MyCommandLineRunner schedulerRunner() {
        return new MyCommandLineRunner(ds);
    }
}

上面的代码产生相同的结果，但不会在 IntelliJ 中报告任何警告。 我很困惑，第二个代码比第一个代码好在哪里？我是否遵循了错误的逻辑？这应该以不同的方式连接吗？

简而言之，正确的方法是什么？

note DataSource只是一个纯粹的例子，这个问题适用于自动连接的任何东西。

note 2只是想说MyCommandLineRunner.java不能有另一个空的构造函数，因为 DataSource 需要自动装配/初始化。会报错，不会编译。

有几种方法可以改进它。

1. 您可以删除@Autowired从你的MyCommandLineRunner当你让@Bean方法构造它的一个实例。注入DataSource直接作为参数进入方法。

2. 或者删除@Autowired并删除@Bean并打一巴掌@Component注释在你的MyCommandLineRunner检测到它并删除工厂方法。

3. 内联您的MyCommandLineRunner在你的里面@Bean方法作为 lambda。

中没有自动装配MyCommandLineRunner

public class MyCommandLineRunner implements CommandLineRunner {
    private final Log logger = LogFactory.getLog(getClass());
    private final DataSource ds;

    public MyCommandLineRunner(DataSource ds) { this.ds = ds; }

    @Override
    public void run(String... args) throws Exception {
        logger.info("DataSource: " + ds.toString());
    }
}

以及应用程序类。

@SpringBootApplication
public class Application {

    public static void main(String... args) {
        SpringApplication.run(Application.class, args); 
    }

    @Bean
    public MyCommandLineRunner schedulerRunner(DataSource ds) {
        return new MyCommandLineRunner(ds);
    }
}

的用法@Component

@Component
public class MyCommandLineRunner implements CommandLineRunner {
    private final Log logger = LogFactory.getLog(getClass());
    private final DataSource ds;

    public MyCommandLineRunner(DataSource ds) { this.ds = ds; }

    @Override
    public void run(String... args) throws Exception {
        logger.info("DataSource: " + ds.toString());
    }
}

以及应用程序类。

@SpringBootApplication
public class Application {

    public static void main(String... args) {
        SpringApplication.run(Application.class, args); 
    }

}

Inline CommandLineRunner

@SpringBootApplication
public class Application {

    private static final Logger logger = LoggerFactory.getLogger(Application.class)

    public static void main(String... args) {
        SpringApplication.run(Application.class, args); 
    }

    @Bean
    public MyCommandLineRunner schedulerRunner(DataSource ds) {
        return (args) -> (logger.info("DataSource: {}", ds); 
    }
}

所有这些都是构建实例的有效方法。使用哪一种，使用你觉得舒服的那种。还有更多选项（此处提到的选项的所有变体）。