Question

依我所知，依赖注入的主要概念是“接口设计”的实践，以使依赖组件彼此松散耦合。但是，我看到许多使用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 Handle Dependency Injection如何缺少理解？

感谢您的指导！

Answer 1

使用接口通常是最佳实践，通常应在自己的代码中使用它（与构造函数注入相比，而不是此字段注入），但对允许的内容过于纯粹的看法会适得其反。

作为示例，我正在使用Amazon DynamoDB，并且需要注入一个DynamoDB类实例。我真的更希望能够注入一个接口，但是Amazon的SDK不提供一个接口，并且能够注入该类的已配置实例仍然比不注入任何接口要好得多。

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

使用注解在Spring中进行依赖注入

1 个答案: