基于 Spring 注释的 DI 与 xml 配置? [英] Spring annotation-based DI vs xml configuration?

问题描述

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

Recently in our team we started discussing using spring annotations in code to define spring dependencies. Currently we are using context.xml to define our dependencies. Would you give me some clues for either approach, and when one is better to be used?

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

I know this seems a duplicate question to a more-general one, but I am interested in the impacts of annotations vs configuration for dependency injection only, which I believe would have different answers and attitude than the general question.

推荐答案

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

After reading some related posts here and having further discussion in the team we come to the following conclusions. I hope the would be useful to others here.

关于 XML 配置(我们一直使用到现在)，我们决定保留它用于库定义的依赖项(无论是由我们开发还是由第三方开发).
库，根据定义，提供特定的功能，可用于各种场景，不一定涉及 DI.因此，在我们自己开发的库项目中使用注解，会创建 DI 框架(在我们的例子中是 Spring)对库的依赖，使库在非 DI 上下文中无法使用.在我们的团队中，拥有额外的依赖项不被认为是一种好的做法(恕我直言).

About XML configuration (which we are using up to now), we decided to keep it for dependencies defined by libraries (regardless if being developed by us, or by third parties).
Libraries, by definition, provide a particular functionality and can be used in various scenarios, not necessarily involving DI. Therefore, using annotations in the library projects we develop ourselves, would create a dependency of the DI framework (Spring in our case) to the library, making the library unusable in non-DI context. Having extra dependencies is not considered a good practice among our team (an in general IMHO).

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

When we are assembling an application, the application context would define the necessary dependencies. This will simplify dependency tracking as the application becomes the central unit of combining all the referenced components, and usually this is indeed where all the wiring up should happen.

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

XML is also good for us when providing mock implementations for many components, without recompiling the application modules that will use them. This gives us flexibility when testing running in local or production environment.

关于注解，我们决定在注入的组件不变的情况下使用注解可以获益——例如，在整个应用程序中只会使用某个组件的特定实现.

In regards to annotations, we decided that we can benefit using them when the injected components will not vary -- for instance only a certain implementation for a component will be used troughout the application.

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

The annotations will be very useful for small components/applications that will not change or support different implementations of a dependency at once, and that are unlikely to be composed in a different way (for instance using different dependencies for different builds). Simple micro-services would fit in this category.

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

Small enough components, made up with annotations, can be used right out of the box in different projects, without having the respective applications to cover them in their XML configuration. This would simplify the application dependency wiring for the application and reduce repetitive setups.

然而，我们同意这些组件应该在我们的技术文档中有很好地描述的依赖关系，这样在组装整个应用程序时，人们就可以知道这些依赖关系，而无需滚动代码，甚至无需在应用程序中加载模块.集成开发环境.

However, we agreed that such components should have the dependencies well described in our technical documentation, so that when assembling the entire application, one can have an idea of these dependencies without scrolling through the code, or even loading the module in the IDE.

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

A negative side effect of annotation-configured components, is that different components could bring clashing transitive dependencies, and again it is up to the final application to resolve the conflicts. When these dependencies are not defined in XML, the conflict resolution approaches become quite limited and straying far from the best practices, if they are at all possible. So, when going with annotations, the component has to be mature enough about what dependencies it is going use.

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

In general if our dependencies may vary for different scenarios, or a module can be used with different components, we decided to stick to XML. Clearly, there MUST be a right balance between both approaches, and a clear idea for the usages.

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

An important update regarding the mixed approach. Recently we had a case with a test framework we created for our QA team, which required dependencies from another project. The framework was designed to use the annotation approach and Spring configuration classes, while the referenced project had some xml contexts that we needed to reference. Unfortunately, the test classes (where we used org.testng with spring support) could only work with either the xml or java configuration classes, not mixing both.

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

This situation illustrates a case where mixing the approaches would clash and clearly, one must be discarded. In our case, we migrated the test framework to use spring xml contexts, but other uses could imply the other way around.

这篇关于基于 Spring 注释的 DI 与 xml 配置?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！