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

我尽可能多地使用全自动接线。我喜欢它。除非受到枪口威胁，否则我不会回到旧式春天。我更喜欢完全的原因@Autowired随着时间的推移而改变。

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

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

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

我会说完全自动装配是 spring 的 ruby​​-on-rails：它包含这样一个概念，即大多数用例都遵循正常和常见的使用模式。使用 XML
配置，您可以 使用 许多一致/不一致的配置，这些配置可能/可能不是预期的。我已经看到很多 xml 配置因不一致而过度使用 -
它是否与代码一起重构？没想到。这些变化是有原因的吗？通常不会。

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

但是，是的，您正在绑定一种特定风格的 DI，而这种风格主要是 spring
所做的。我们甚至不再为依赖项创建公共设置器（所以你可以说我们在封装/信息隐藏部门是 +1）我们的系统中仍然有一些 xml，但 xml 基本上 只
包含异常。完全自动装配与 xml 很好地集成。

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