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

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

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

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

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

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

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

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

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