Spring - 需要带注释的依赖注入

Question

我试图了解Spring依赖注入和自动布线的基础知识。所有教科书都说，依赖注入的主要优点是你可以通过修改XML来修改应用程序而不需要触及java代码。

但是，当你使用注释时，这个目的就被打败了！那有什么大不了的？为什么不只是实例化它而不是注入额外的代码呢？

Answer 1

在早期版本的Spring中，所有注入都必须使用XML完成。对于大型项目，XML本身变得非常庞大，难以维护或繁琐。对代码中依赖项的更改需要XML中的相应更改。添加自动布线是为了减少XML的大小。

但是，自动布线不会降低依赖注入，因为可以使用XML来覆盖它。这给出了XML配置的原始灵活性，方便了Spring允许默认情况下在实现接口的上下文中只有一个可能的bean。

你的问题似乎在于问我们为什么要依赖注入：＆＃34;为什么不只是实例化它而不是注入额外的代码？＆＃34;。依赖注入的最常见用途之一是单元测试：测试程序将依赖项的测试版本注入到测试对象中以打破进一步的依赖性。例如，如果服务类A调用服务类B，并且B依赖于数据库对象，其他服务，文件系统等，那么如果A直接实例化B，则测试A变得非常困难，因为您需要确保所有B的依赖性得到满足。如果A被编码为接口iB而不是B类，则单元测试代码可以注入实现iB的测试类的实例，并且响应方法调用而没有任何进一步的依赖性。

Answer 2

我相信有很多开发人员认为，如果你想构建持久可维护的代码，你应该遵守SOLID-principles。

SOLID中的 D 代表依赖性反转原则，它基本上是指<​​em>依赖注入。因此，如果您希望保持代码清洁并将对象创建与实际业务代码分开，那么依赖注入是一件好事。此外，DI使我的代码更易于测试。

你是对的，@Autowired等注释会侵扰你的代码，但你不必改变逻辑或任何东西，只需注释方法。

处理依赖注入的另一种方法是通过@Configuration和@Bean注释使用Java配置（请参阅Spring docs）。如果您真的担心将@Autowired添加到代码中，那么Java配置就不那么具有侵入性了。

这个SO-question很好地概述了为什么DI很重要而且很好。该帖子的一句话是：

  

依赖注入基本上是提供对象所需的对象（它的依赖关系），而不是让它自己构造它们。它是一种非常有用的测试技术，因为它允许模拟或删除依赖项。

Answer 3

可以控制服务实例和松散耦合，您可以在注释中注入任何实现所请求接口的类。