与 xml 配置文件相比，注释（非编译器）的优点/缺点是什么答案

【问题标题】：What are the Pros/Cons of Annotations (non-compiler) compared to xml config files与 xml 配置文件相比，注释（非编译器）的优点/缺点是什么
【发布时间】：2009-07-10 11:08:07
【问题描述】：

当我查看 Hibernate、JPA 或 Spring 等 Java 框架时，我通常可以通过 xml 文件进行配置或将注释直接放在我的类中。

我一直在问自己应该走哪条路。

当我使用注释时，我将类及其配置放在一起，但使用 xml 我可以更全面地了解我的系统，因为我可以看到所有类配置。

注释也会以某种方式编译，我猜它应该比解析 xml 更快，但另一方面，如果我想更改我的配置，我必须重新编译它而不是仅仅更改 xml 文件（这可能对于客户端的生产环境变得更加方便）。

因此，在查看我的观点时，我倾向于采用 xml 方式。但是在查看论坛或教程时，通常会使用注释。

你的优点和缺点是什么？

【问题讨论】：

标签： java annotations

【解决方案1】：

一个好的经验法则：任何你可以看到自己想要在没有完全重新部署的情况下进行更改的东西（例如调整性能参数）都应该真正放入“可软配置”的东西中，例如 XML 文件。任何实际上永远不会改变的东西——或者只有在你不得不改变代码的那种情况下——都可以合理地放在注释中。

忽略注释和 XML 之间性能差异的任何想法 - 除非您的配置绝对大量差异将是微不足道的。

专注于灵活性和可读性。

【讨论】：

谢谢。我没有想过同时使用两者。
注解具有附加到代码的优势。因此，与单独的文件相比，它们不同步的可能性更小。确保单独文件中的任何选项都被单元测试彻底覆盖。也就是说，最好的办法是听从上面的建议。
根据部署到的环境（QA 与生产环境）或需要由进行部署的人员提供的值（例如数据库密码）而有所不同的值也适用于外部配置。
另外，使用 AOP，注解更像是 lisp-y 宏。例如您可以在代码中看到它们，它们并没有隐藏在不相关的文件中。

【解决方案2】：

如果您正在编写 API，请注意：注释可能会泄漏到您的公共界面中，这可能会令人难以置信。

我目前正在使用 API，API 供应商在他的实现中添加了 Spring MBean 注释，这突然意味着我依赖于 Spring 库，尽管我可能根本不需要使用 Spring： (

（当然，如果您的 API 是 Spring 本身的扩展，这可能是一个有效的假设。）

【讨论】：

注解不会导致运行时依赖。请参阅this comment 了解它。

【解决方案3】：

我认为决定归结为“生命周期”，以及生命周期之间的阻抗不匹配。

生命周期： 每一条数据，无论是其源代码、数据库行、编译的类还是对象，都有一个与之关联的生命周期。它是什么时候出现的，什么时候被垃圾回收的？

假设我将 Hibernate 注释放在 Java 类上。似乎是一个合理的想法，特别是如果我从头开始创建一个新数据库并且确信只有这个应用程序会连接到它 - 我的类的生命周期、数据库模式和 ORM 映射自然是同步的。

现在假设我想在 API 中使用同一个类并将其提供给第三方使用。 Hibernate 注释泄漏到我的 API 中。发生这种情况是因为该类和数据库的生命周期不是一回事。所以我们最终使用映射工具在系统中的 bean 层之间进行转换。

我尝试考虑生命周期，并且应该避免可能导致生命周期不匹配的注释。有的注解在这方面相对无害，有的则是隐患。

错误注释示例： ORM 映射、数据库配置、可能因部署环境而异的项目的硬编码配置、可能因上下文而异的验证。

无害注释示例： REST 端点定义、JSON/XML 序列化、始终适用的验证。

【讨论】：