弹簧@Autowired用法

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

我尽可能多地使用全自动接线。我喜欢。我不会回到老式的春天，除非在枪口下受到威胁。我选择完全的理由随着时间的推移而改变。@Autowired

现在，我认为使用自动布线的最重要原因是系统中需要跟踪的抽象减少了一个。“豆名”实际上已经消失了。事实证明，Bean 名称只是因为 xml 而存在。因此，一整层抽象的间接寻址（你可以将bean名称“foo”连接到bean“bar”）消失了。现在，我将“Foo”接口直接连接到我的Bean中，并通过运行时配置文件选择实现。这使我可以在跟踪依赖项和实现时使用代码。当我在代码中看到自动连接的依赖项时，我只需在IDE中按“转到实现”键，然后列出已知实现的列表。在大多数情况下，只有一个实现，我直接进入了类。没有比这更简单的了，而且我总是确切地知道正在使用的实现（我声称相反的情况更接近xml连接的事实 - 有趣的是你的观点是如何变化的！

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

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

我想说的是，完全自动布线是Spring的红宝石：它包含了这样一种概念，即大多数用例都遵循正常和常见的使用模式。使用 XML 配置，您可以允许大量一致/不一致的配置用法，这些用法可能/可能不是预期的。我已经看到太多的xml配置因不一致而过分 - 它是否与代码一起重构？不以为然。这些变化是有原因的吗？通常不会。

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

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

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

对我来说，这是我喜欢/不喜欢Spring和自动布线的原因。

优点：

• 自动布线摆脱了令人讨厌的XML配置。
• 使用注释要容易得多，它允许您使用字段，setter方法或构造函数直接注入。还允许您注释和“限定”注入的豆子。

缺点：

• 使用自动布线和注释使您依赖于Spring库，与XML配置一样，您可以选择使用或不使用Spring运行。就像你说的，你被一个DI框架所束缚。
• 同时，我喜欢能够“限定”bean，对我来说，这使得代码变得非常混乱。如果你需要在多个地方注入相同的bean，我看到相同的字符串名称到处重复。对我来说，这似乎有出错的可能性。

我已经开始几乎完全在工作中使用自动布线，因为我们非常依赖Spring集成，以至于依赖性问题没有实际意义。我参与了一个Spring MVC项目，该项目广泛使用自动布线，并且有点难以理解。

我认为自动布线是一种后天习得的味道，一旦你习惯了它，你就会意识到它比XML配置更强大，多么容易，而且使用起来不那么令人头疼。