-1

依赖注入的主要概念——据我所知——是“为接口设计”的实践，以使依赖组件彼此松散耦合。但是，我看到许多使用 Spring 开发的系统 - 在我看来 - 违反了这个概念 [并且 Spring Container 在语法级别允许这样做]。在看到这样的代码/实现之后，我开始质疑我对依赖注入作为一个概念的知识/理解。

我经常看到组件通过它们的具体实现自动连接到彼此，这是我的意思的一个例子：

@RestController
public class MyRestController {
    @AutoWired
    private MyServiceOne serviceOne;
    // .. rest of the code if the rest controller here ...
}
@Service
public class MyServiceOne {
    @Autowired
    private MyRepository repo;
    // rest of code of the service here
}

正如你所看到的，“MyServiceOne”是一个具体的类，而不是一个接口，Spring Framework 可以接受。不需要在某个“@Configuration”类中提供“@Bean”方法来注入正确的具体类类型[因为@service已经是一个具体类]。

因此，对于服务层中的任何更改/自定义[控制器中的注入依赖项]，我将不得不更改控制器中的以下行：

@AutoWired
private MyServiceOne serviceOne; //change this to be another service class, or a service class that extends it

这不是松耦合！[或者是吗？] 在我看来，如果我们要以这种方式使用 Spring DI，最好不要使用它！在应用程序内存中创建了许多 maven/Gradle 依赖项和运行时对象！

我想知道，在我对依赖注入如何作为一个概念/或 Spring 如何处理依赖注入的理解中是否缺少一些东西？

感谢您的指导！

4

1 回答 1

1

使用接口通常是一种最佳实践，并且您通常应该在自己的代码中更喜欢它（以及构造函数注入而不是此字段注入），但是对于允许的内容过于纯粹会适得其反。

例如，我正在使用 Amazon DynamoDB，我需要注入一个DynamoDB类实例。我真的更喜欢能够注入一个接口，但亚马逊的 SDK 没有提供一个接口，并且能够注入配置的类实例仍然比什么都不注入要好得多。

同样，在 Spring Boot 中注入 bean 并不少见@ConfigurationProperties，它们基本上是类似结构的 POJO，没有逻辑。在这种情况下，定义接口只是浪费时间，但是通过（具体）类型注入 bean 的能力非常有用。

于 2018-12-18T19:11:49.767 回答