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

Posted 2023-02-25

【中文标题】基于 Spring 注释的 DI 与 xml 配置？

【英文标题】：Spring annotation-based DI vs xml configuration?

【发布时间】：2012-01-15 17:44:07

【问题描述】：

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

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

【问题讨论】：

Xml configuration versus Annotation based configuration的可能重复

是的，这个问题非常接近，但我的印象是它通常针对 xml 与注释。我只对依赖注入感兴趣。

【参考方案1】：

使用XML配置的一些优点：

XML 配置在一个地方，而不是分散在源代码中以防出现注释。有些人可能会争辩说，像 STS 这样的 IDE 允许您在一个地方查看所有基于注释的配置，但我从不喜欢依赖于 IDE。 编写 XML 配置需要花费更多的精力，但在以后搜索依赖项并尝试了解项目时会节省大量时间。 XML 使配置保持良好的组织性和简单性。因此更容易理解，它有助于新的相对缺乏经验的团队成员快速上手。 允许您更改配置而无需重新编译和重新部署代码。因此，在生产支持方面更好。

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

2.5 年后：

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

【讨论】：

我们有 7 个 XML 文件，每个文件 12,000 行。这并不能节省时间，而且只会让每个人都头疼。

我们通常在模块中组织代码（无论是 xml、java、groovy 还是任何其他语言）。您应该考虑拥有多个 xml 文件（每个特定于一个模块或子模块）。

想象一下注释中的 12000 个 xml 配置行...

【参考方案2】：

我们无法判断哪种方法好，这取决于您的项目。我们既不能避免xml也不能注释。使用 xml 的一个好处是我们可以通过查看 xml 上下文文件来理解项目结构，但是注解减少了很多元配置。所以我更喜欢 30% 的 xml 和 70% 的注解。

【参考方案3】：

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

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

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

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

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

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

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

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

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

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

---

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

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

【参考方案4】：

注解是否比 XML 更适合配置 Spring？

基于注解的配置的引入提高了 这种方法是否比 XML“更好”的问题。短的 答案是视情况而定。长答案是每种方法都有其 利弊，通常由开发人员决定 战略更适合他们。由于它们的定义方式， 注释在其声明中提供了很多上下文，导致 更短更简洁的配置。但是，XML 擅长布线 向上组件没有

接触他们的源代码或重新编译它们。一些开发者更喜欢 使布线靠近源，而其他人则认为 带注释的类不再是 POJO，而且， 配置变得分散且难以控制。

无论选择什么，Spring 都可以适应两种风格，甚至可以混合 他们在一起。值得指出的是，通过它的 JavaConfig 选项，Spring 允许以非侵入性方式使用注释， 无需触及目标组件源代码 的工具，所有的配置样式都被 Spring Tool 支持 套房。

我个人的选择是 xml 更好，因为您可以在一个地方拥有所有内容，并且您无需深入到包中来搜索类。

【参考方案5】：

根据我自己的经验，注解比xml配置好。我认为无论如何您都可以覆盖 xmls 并使用注释。此外，Spring 4 为我们提供了对注解的巨大支持，我们可以覆盖从 xml 到注解等的安全性，因此我们将拥有 100 行 xml 而不是 10 行 Java 代码。

【讨论】：

我对注释的问题是我没有清楚地了解事物是如何连接的，配置了什么等等。我必须'搜索;在源文件中。你如何处理这种情况？

“查找用法”比对所有源文件进行字符串搜索更容易使用

【参考方案6】：

在此处查看此答案：Xml configuration versus Annotation based configuration

直接来自那里的简短引用：

注释有其用处，但它们不是唯一的灵丹妙药 杀死 XML 配置。我建议将两者混合使用！

例如，如果使用 Spring，将 XML 用于 应用程序的依赖注入部分。这得到 代码的依赖项远离将要使用它的代码，通过 相反，在需要的代码中使用某种注释 依赖项使代码知道这种自动配置。

但是，不是使用 XML 进行事务管理，而是标记一个 带有注释的事务性方法非常有意义，因为 这是程序员可能希望知道的信息。

编辑：另外，看看这里的答案：Java Dependency injection: XML or annotations 他们很可能会更好地针对您感兴趣的领域。

【讨论】：

谢谢，一个非常相似的问题。但是，我很感兴趣这两种方法仅对 DI 会产生什么后果，而不是一般情况下。我还编辑了我的问题以减少混淆。

看看这个：***.com/questions/4995170/…

【参考方案7】：

根据我的经验，我更喜欢（或者更确切地说是受限制）结合使用 XML 和基于注释的 DI 。如果我需要在 bean 中注入元素 Map，我必须定义一个 util:map 并自动装配它。另外，如果我有多个数据源等等，我需要使用 XML DI 将数据源注入 sessionFactory。所以需要两者结合。

我更喜欢使用组件扫描来自动检测服务和 Dao 。这减少了很多配置（我们通过切换到组件扫描减少了大约 50% 的配置文件）。基于注解的 DI 支持 byName(@Resource) 和 byType(@Autowired)。

简而言之，我的建议是两者兼而有之。我觉得在未来的 Spring 版本中肯定会提供更多的注释支持。