基于弹簧注释的 DI 与 xml 配置？

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

关于XML配置（到目前为止我们正在使用），我们决定将其保留为由库定义的依赖项（无论是由我们还是由第三方开发）。
根据定义，库提供特定的功能，并且可以在各种方案中使用，而不一定涉及 DI。因此，在我们自己开发的库项目中使用注释，将创建DI框架（在我们的例子中是Spring）对库的依赖关系，使库在非DI上下文中不可用。在我们的团队中，拥有额外的依赖关系不被认为是一种好的做法（恕我直言）。

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

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

关于注释，我们决定，当注入的组件不会改变时，我们可以使用它们 - 例如，在整个应用程序范围内仅使用组件的某个实现。

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

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

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

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

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

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

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

使用 XML 配置的一些优点：

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

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

2.5年后：

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