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

当我看到像Hibernate，JPA或Spring这样的Java框架时，我通常可以通过xml文件进行配置或直接在我的类中添加注释。

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

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

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

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

你有什么优缺点？

一个好的经验法则：你可以看到自己想要在没有完全重新部署的情况下进行更改的任何事情（例如，调整性能参数）都应该采用“软配置”的方式，例如XML文件。任何从未真正改变的东西 – 或者只是在你不得不改变代码的情况下 – 可以合理地在注释中。

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

专注于灵活性和可读性。

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

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

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

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

生命周期：每一段数据，无论是源代码，数据库行，编译类，对象，都有与之相关的生命周期。什么时候出现，什么时候收集垃圾？

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

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

我试着考虑生命周期，应该避免可能导致生命周期不匹配的注释。在这方面，有些注释相对无害，有些是隐藏的危险。

错误注释的示例： ORM映射，数据库配置，可能在部署环境之间变化的项目的硬编码配置，可能根据上下文而变化的validation。

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