@Autowired 与 XML

Question

总的来说，我对 Spring 和 DI 很陌生。但据我所知，DI 使您能够使用

Spring

等框架非常轻松地更换实现。当涉及到 XML bean 配置时，我可以理解那里的价值，因为根本不需要更改代码来完成可切换的实现。但如果我们使用像

@Autowired

或

@Qualifier

这样的注释...我们就需要更改代码。那么为什么我们要在基于 XML 的配置上使用注释呢？

Answer 1

这实际上是 2009 年 Spring 3.0 发布并将 JavaConfig 添加到核心系统基础时的一个热烈讨论的话题。

理论上，能够外部化应用程序设置是一件很棒的事情。然而，事实证明，实际上有两组不同的设置选择：应用程序形状或依赖关系图，以及 API 密钥、数据库连接字符串等特定值，这些值因环境而异，但通常不会改变方式豆子是有线的。

经验表明，依赖图（本质上就是您在 XML 中表达的内容）几乎永远不会更改，除非同时更改随附的实现代码，因此在 XML 中定义图几乎没有实际好处。另一方面，用 Java 编写

@Bean

方法意味着在需要时更容易测试配置，编译器可以确保类型安全，并且决策逻辑（例如条件）更容易实现。

此外，注释的可用性意味着可以在 Java 中相当轻松地扩展特定于领域的语言以进行配置——只需创建一个新的注释及其随附的处理器（例如

@ConditionalOnProperty

）； Spring Boot 本身就是该模型灵活性的一个极端例子。另一方面，在 XML 中，将新标签或属性注入到模式中则要麻烦得多。

有时 XML 可能仍然是更好的选择（我特别用它来编写 Spring Integration 管道，它在 XML 中比在 Java DSL 中更容易阅读），但现实世界的好处已经证明在大多数情况下并没有那么有价值，并且配置即代码的安全性和灵活性已经胜出。

Answer 2

这不是必须的，您必须选择使用注释或 XML，这取决于您，但注释易于使用，比配置更快且更具可读性，并且当您使用它时，您会在单个文件中找到所有信息，但是它也有缺点。

最好有注释

在任何稳定且定义核心的内容中使用注释 应用程序的结构。任何需要更改代码的内容 坐当注释也可以啊

我建议您阅读以下链接以获取更多信息：
xml 配置与基于注释的配置
spring-framework-xml-与注释

Answer 3

我在一个开发和运营之间有明确分离的组织，任何形式的产品变更的推广都是通过严格的批准/测试流程来完成的。我们基于 Spring 的应用程序/服务中的 Bean 接线最初是使用 XML 完成的，我们认为这将为我们带来两个好处：

1. Spring 完成的所有连线都是集中式的，通过检查 xml 文件，人们可以轻松地找出什么与什么连接，并且
2. 它允许我们的运营团队在需要时更改应用程序的某些方面。

一段时间后，事实证明，第二个原因/好处实际上从未实现，首先，如果不经过正式验证过程，就不会容忍应用程序行为的任何变化，这意味着应用程序的另一个版本（这将是与代码更改没有什么不同），其次，运营团队对应用程序内部结构没有足够的了解，无法有信心干预 XML。另外，生产环境中唯一可用的编辑器是 vi，而且在少数情况下，他们确实需要更改 XML，结果证明这是一个真正的痛苦，因为他们没有意识到 XML 标签没有正确关闭。他们最终“配置”的唯一方面实际上只是端口、IP 地址、超时、缓冲区大小等内容，这些内容无论如何都位于易于修改的属性文件中。

因此，使用 XML 作为一种自记录应用程序互连的唯一可感知的好处是我们——开发团队。然而最终我们开始放弃 XML 并越来越多地使用注释，因为我们发现它们更容易编码，加上流行的 IDE 和 spring 插件使得弄清楚依赖关系/互连变得相当容易。