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

Question

最近在我们的团队中，我们开始讨论在代码中使用spring注释来定义spring依赖项。目前我们使用context.xml来定义依赖项。你能不能给我一些线索，哪一种方法更适合使用？

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

Answer 1

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

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

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

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

关于注释，我们决定当注入的组件不会变化时我们可以使用它们 - 例如，只有某个组件的某个实现将在整个应用程序中使用。

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

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

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

注释配置组件的负面影响是，不同的组件可能会带来冲突的传递依赖关系，同样由最终的应用程序来解决冲突。当这些依赖关系没有在XML中定义时，冲突解决方法变得非常有限，并且如果它们尽可能地远离最佳实践则偏离。 因此，在使用注释时，组件必须足够成熟，以了解它将使用哪些依赖项。

通常，如果我们的依赖关系可能因不同的场景而异，或者模块可以与不同的组件一起使用，我们决定坚持使用XML。显然，两种方法之间必须存在正确的平衡，以及对使用的明确想法。

---

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

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

Answer 2

根据我的经验，我更愿意（或者更确切地说是受到限制）使用XML和基于注释的DI的组合。如果我需要在bean中注入一个元素Map，我将不得不定义一个util：map并自动装配它。另外，如果我有多个数据源，我需要使用XML DI将数据源注入sessionFactory，依此类推。因此，两者的组合将被要求。

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

简而言之，我建议你去寻找两者。我觉得在未来的Spring版本中肯定会有更多的注释支持。

Answer 3

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

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

  

注释有它们的用处，但它们不是一颗银弹   杀死XML配置。我建议将两者混合使用！

     

例如，如果使用Spring，使用XML是完全直观的   应用程序的依赖注入部分。这得到了   代码的依赖性远离将要使用它的代码   相比之下，在需要的代码中使用某种注释   依赖关系使代码知道这种自动配置。

     

但是，不是使用XML进行事务管理，而是标记一个   因为具有注释的事务方法具有完美的意义   这是程序员可能希望了解的信息。

编辑：另外，请看一下这里的答案：Java Dependency injection: XML or annotations他们最有可能更好地定位您感兴趣的领域。

Answer 4

使用 XML配置的一些优点：

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

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

Answer 5

从我自己的经验注释比xml配置更好。我想在任何情况下你都可以覆盖xmls并使用注释。 Spring 4也为注释提供了巨大的支持，我们可以覆盖从xml到注释e.t.c的安全性，所以我们不会有100行xml而是10行Java Code。

Answer 6

  

在配置Spring时，注释是否比XML更好？

     

基于注释的配置的引入使   这个方法是否比XML“更好”的问题。短   答案是取决于。长答案是每种方法都有其自己的   利弊，通常由开发者决定   策略更适合他们。由于定义方式不同，   批注在其声明中提供了很多上下文，从而导致   更短，更简洁的配置。但是，XML擅长接线   组件没有

     

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

     

无论选择如何，Spring都可以容纳两种样式，甚至可以混合使用   他们在一起。值得指出的是，通过其JavaConfig   选项，Spring允许以非侵入方式使用注释，   无需触及目标组件的源代码和术语   在工具方面，Spring Tool支持所有配置样式   套房。

我个人的选择是xml更好，因为您可以将所有内容都放在一个位置，而无需深入研究软件包来搜索类。

Answer 7

我们无法确定哪种方法是好的，这取决于您的项目。我们可以避免使用xml或注释。使用xml的优点之一是，仅查看xml上下文文件，我们就可以了解项目结构，但是注释减少了许多元配置。所以我更喜欢30％的xml和70％的注释。