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

Question

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

编辑：我知道这似乎是对更一般的问题的重复问题，但是我对仅依赖注入的注解和配置的影响感兴趣，我相信与一般问题相比，注解和配置的影响会有所不同。

Answer 1

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

关于XML配置 （我们一直使用到现在），我们决定将其保留为库定义的依赖项（无论是由我们还是由第三方开发）。
顾名思义，库提供了特定的功能，可以在各种情况下使用，而不必涉及DI。因此，在我们自己开发的库项目中使用注释，将创建DI框架（在本例中为Spring）对库的依赖关系，从而使该库在非DI上下文中不可用。在我们的团队（通常是恕我直言）中，拥有额外的依赖关系不是一个好习惯。

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

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

关于注释 ，我们决定在注入的组件不变的情况下使用它们会受益匪浅-例如，在整个应用程序中仅使用某个组件的特定实现。

对于不会立即更改或支持依赖关系的不同实现且不太可能以不同方式（例如，对不同构建使用不同依赖关系）组成的小型组件/应用程序，注释将非常有用。简单的微服务将适合此类别。

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

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

注释配置的组件的负面影响是，不同的组件可能会带来冲突的传递依赖关系，这又取决于最终的应用程序来解决冲突。如果未在XML中定义这些依赖项，则冲突解决方法将变得非常有限，并且如果可能的话，也会偏离最佳实践。因此，在使用批注时，组件必须充分了解要使用的依赖项。

通常，如果我们的依赖关系可能因不同的情况而有所不同，或者一个模块可以与不同的组件一起使用，那么我们决定坚持使用XML。显然，两种方法之间必须有 适当的
平衡，并且必须有明确的用法构想。

有关混合方法的重要更新。最近，我们为质量保证团队创建了一个测试框架案例，该框架需要另一个项目的依赖。该框架旨在使用注释方法和Spring配置类，而被引用的项目具有一些我们需要引用的xml上下文。不幸的是，测试类（我们在其中使用org.testng了Spring支持）只能与xml或Java配置类一起使用，而不能将两者混合使用。

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