Spring @Autowired用法

Question

在Spring会连接的类中使用 @Autowired的 优缺点是什么？

只是为了澄清，我是在专门谈论 @Autowired 注释，而不是XML的自动 装配 。

我可能只是不了解它，但是对我来说，这几乎就像是一种反模式-
您的类开始意识到它们与DI框架相关联，而不仅仅是POJO。也许我是惩罚的嘴，但我喜欢为bean设置外部XML配置，并且我喜欢使用显式的接线，因此我确切知道在哪里接线。

Answer 1

很长时间以来，我相信拥有像我们所有人过去使用的xml文件一样的“集中式，声明式配置”是有价值的。然后我意识到文件中的大多数内容都不是 配置
-开发后从未在任何地方进行过更改。然后我意识到，“集中”只有在非常小的系统价值-只有在小型系统会你永远能够神交配置文件 作为一个整体
。当相同的“接线”主要由代码中的依赖项复制时，理解接线整体的真正价值是什么？因此，我唯一保留的是元数据（注释），它仍然是声明性的。这些 永远不会
在运行时更改，也 永远不会 有人会即时更改的“配置”数据-所以我认为将其保存在代码中很好。

我会尽量使用全自动接线。我喜欢它。除非有枪口威胁，否则我不会回到老式的春天。@Autowired随着时间的流逝，我完全喜欢的理由已经改变。

现在，我认为使用自动装配的最重要原因是系统中要跟踪的抽象较少。“
bean名称”实际上已经消失了。事实证明，由于xml，bean名称仅存在。因此，完整的抽象间接层（将bean名称“ foo”连接到bean“
bar”的地方）消失了。现在，我将“ Foo”接口直接连接到我的bean中，并通过运行时配置文件选择实现。这使我可以在跟踪依赖关系和实现时 使用代码
。当我在代码中看到自动装配的依赖项时，只需在IDE中按“转到实现”键，然后出现已知实现的列表。在大多数情况下，只有一个实现，而我直接进入课堂。能够’
__正在使用什么实现（我声称与xml连线相反的事实更接近真相-有趣的是您的观点如何改变！）

现在您可以说这只是一个非常简单的层，但是我们添加到系统中的每个抽象层都会 增加 复杂性。我真的不认为xml可以为我使用过的任何系统增加任何实际价值。

我曾经使用过的大多数系统只有 一个 生产运行时环境的配置。可能还有其他测试配置等等。

我想说的是，自动装配是春天的红宝石：它包含了这样一种观念，即大多数用例都遵循一种正常且通用的使用模式。使用XML配置，您可以 允许
/可能不希望使用大量一致/不一致的配置。我已经看到太多的xml配置因不一致而泛滥成灾-它会与代码一起重构吗？以为没有。这些变化是有原因的吗？通常不会。

我们几乎没有在配置中使用限定符，而是找到了解决这些情况的其他方法。这是我们遇到的一个明显的“缺点”：我们已经稍微改变了编码方式，使其与自动装配的交互更加流畅：客户存储库不再实现通用Repository<Customer>接口，而是使接口CustomerRepository可扩展Repository<Customer>。有时在子类化方面还有一两个窍门。但这通常只是为我们指明了更强类型化的方向，我发现这几乎总是一个更好的解决方案。

但是，是的，您绑定的是大多数spring都采用的特定DI风格。我们甚至不再为依赖项设置公共设置器（因此，您可以说我们在封装/信息隐藏部门中为+1）。我们的系统中仍然有一些xml，但是xml基本上
只 包含异常。完全自动装配与xml很好地集成在一起。

现在，我们唯一需要的就是将@Component，@Autowired其余的都包含在JSR中（例如JSR-250），因此我们不必与spring捆绑在一起。这就是过去发生的事情的方式（这些java.util.concurrent东西浮现在脑海中），所以如果再次发生这种情况，我不会感到完全惊讶。