基于 Spring 注解的 DI 与 xml 配置？

Question

最近在我们的团队中，我们开始讨论在代码中使用 spring 注释来定义 spring 依赖项。目前我们正在使用 context.xml 来定义我们的依赖项。你能给我一些关于这两种方法的线索吗？什么时候最好使用？

编辑：我知道这对于一个更一般的问题来说似乎是一个重复的问题，但我只对依赖注入的注释与配置的影响感兴趣，我相信这与一般问题会有不同的答案和态度。

原文由 Ivaylo Slavov 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

在阅读了此处的一些相关帖子并在团队中进行了进一步讨论后，我们得出以下结论。我希望对这里的其他人有用。

关于 XML 配置（我们目前正在使用），我们决定将其保留用于库定义的依赖项（无论是由我们开发还是由第三方开发）。

库，顾名思义，就是提供一个特定的功能，可以用在各种场景中，不一定涉及DI。因此，在我们自己开发的库项目中使用注解会创建 DI 框架（在我们的例子中是 Spring）对库的依赖，使库在非 DI 上下文中无法使用。在我们的团队中，拥有额外的依赖关系不被认为是一种好的做法（通常恕我直言）。

当我们组装应用程序时，应用程序上下文将定义必要的依赖项。这将简化依赖关系跟踪，因为应用程序成为组合所有引用组件的中央单元，通常这确实是所有连接应该发生的地方。

XML 在为许多组件提供模拟实现时也对我们有好处，而无需重新编译将使用它们的应用程序模块。这为我们在本地或生产环境中测试运行时提供了灵活性。

关于注解，我们决定在注入的组件不会发生变化时使用它们会受益——例如，在整个应用程序中只会使用某个组件的特定实现。

这些注解对于小型组件/应用程序非常有用，这些组件/应用程序不会立即更改或支持依赖项的不同实现，并且不太可能以不同的方式组合（例如，对不同的构建使用不同的依赖项）。简单的微服务就属于这一类。

足够小的组件，由注释组成，可以在不同的项目中开箱即用，而不需要相应的应用程序在它们的 XML 配置中覆盖它们。这将简化应用程序的应用程序依赖布线并减少重复设置。

但是，我们同意这些组件应该具有我们的技术文档中详细描述的依赖关系，以便在组装整个应用程序时，无需滚动代码甚至无需在 IDE 中加载模块就可以了解这些依赖关系。

注解配置组件的一个负面影响是，不同的组件可能会带来相互冲突的传递依赖关系，而最终应用程序又要解决这些冲突。当这些依赖关系未在 XML 中定义时，冲突解决方法变得非常有限并且偏离最佳实践（如果可能的话）。因此，在使用注释时，组件必须足够成熟，知道它要使用的依赖项。

一般来说，如果我们的依赖关系可能因不同的场景而异，或者一个模块可以与不同的组件一起使用，我们决定坚持使用 XML。显然，两种方法之间必须有一个 正确 的平衡，并且对用法有一个清晰的想法。

---

关于混合方法的重要更新。最近我们有一个案例，我们为 QA 团队创建了一个测试框架，它需要来自另一个项目的依赖项。该框架旨在使用注释方法和 Spring 配置类，而引用的项目有一些我们需要引用的 xml 上下文。不幸的是，测试类（我们使用 org.testng 支持 spring）只能使用 xml 或 java 配置类，不能混合使用。

这种情况说明了一种情况，混合方法会发生冲突，并且显然必须丢弃一种方法。在我们的例子中，我们迁移了测试框架以使用 spring xml 上下文，但其他用途可能意味着相反的方式。

原文由 Ivaylo Slavov 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 2

使用 XML 配置 的一些优点：

1. XML 配置在一个地方，而不是在注释的情况下分散在整个源代码中。有些人可能会争辩说像 STS 这样的 IDE 允许您在一个地方查看所有基于注释的配置，但我从不喜欢依赖 IDE。
2. 编写 XML config 需要更多的努力，但是当您搜索依赖项并尝试了解项目时，它会节省很多时间。
3. XML 使配置井井有条且简单。因此更容易理解，它可以帮助相对缺乏经验的新团队成员快速上手。
4. 允许您更改配置而无需重新编译和重新部署代码。所以在生产支持方面更好。

所以简而言之，XML 配置需要更多的努力，但它可以为您节省大量的时间和以后在大型项目中的麻烦。

2.5年后：

这些天我们主要使用注释，但最重要的变化是我们创建了许多小项目（而不是一个大项目）。因此，理解依赖关系不再是问题；因为每个项目都有其独特的目的和相对较小的代码库。

原文由 Pritesh Mhatre 发布，翻译遵循 CC BY-SA 4.0 许可协议