前几天，我根据 Spring XML vs. Annotations 后的原则轻松地进入了这个主题。这个简单的入口也是我不让我的团队复杂化的方法，他们目前正在参与编写这个可能有 3-5 年生产寿命的新应用程序（如果我们做对了，希望技术不会'不会在一夜之间改变）。
我从 1.1 开始就一直在使用 Spring Days，所以是的，我对处理非常大和复杂的 XML 集有一定程度的舒适感。我知道如何写它们，更重要的是我知道如何阅读它们。从那时起，Spring 使开发人员可以轻松地使用带有 Beans Explorer / Graph 的 Spring STS 来理解它们。开发人员不再需要担心查看多个 XML 集——这些工具为我们完成了工作，甚至为他们编写和管理 bean。
我们牺牲了编写良好和高性能代码的艺术，以换取提高开发人员生产力的短期收益
自从我看到 Spring 3.x 引入了这种基于注解的配置概念以来，使用这些注解而不是使用 XML 的炒作至少在 7 年里一直很火（如果我没记错的话）。我一直无法接受这种方向上的变化。并不是说它不好，但事实是这个特性已经被社区滥用到它的核心，而 Spring 一直在促进滥用。今天任何 Spring 文档都在谈论注释样式的编码，只是为了遵循“经典的 XML 方式”做事。
虽然人们说 - 阅读代码更容易 ，并且 在混合中使用注释调试代码更容易 。他们忘记了他们现在已经在代码中嵌入了配置。从我记事起，配置就应该是外部化的。在我们使用 Hibernate 和 JPA 等 ORM 框架的情况下，问题会更加严重。
即使在原始的 Spring Design 中，即使使用 XML，我也觉得我们如何设置 spring 应用程序并不是 spring 的设计目的。是时候让我去了解一下 Rod Johnson 在设计 Spring 时的想法（我知道他的一些意图，但我需要了解更多细节并深入了解）。但那是另一天。
因此，让我们看看 这篇解释将 JPA 与 Spring 结合使用的博客文章 ，或者阅读 这个 StackOverFlow 线程 。好吧，他们都解释了如何去做，但很快我们就意识到在代码中使用这些所谓的基于丰富注释的配置会淡化代码/设计的整体含义。当我必须在个人喜欢的项目中尝试一些新东西以快速起步时，这种编程风格非常棒——我只需编写一个类，输入一些注释和 boom ，我就可以开始 CRUD 了。但这真的适用于企业级应用程序，特别是考虑到我们如何在生产中管理它。
这些文章只不过是一堆营销/销售宣传，希望我们去使用这些框架和新功能，但他们很少将事情放在我们必须在大型生产系统中处理的复杂情况的背景下。
2007 年，我们在我们的项目中广泛使用了 Hibernate（使用基于 XML 配置的 Spring 2.x），我们很快意识到我们已经超越了 ORM 框架的限制。我们有一些复杂的查询，我们试图将其改造到 Hibernate 中，并且我们会触发任何可以用 MS-SQL 编写的查询，从而造成一个主要的瓶颈。我是该框架的新手，但更重要的是，我的技术领导层大力推动我充分利用 Hibernate。这些人可以访问我之前分享的文章，这看起来是合乎逻辑的方式，但它们只不过是营销文章，旨在销售 Hibernate 和 ORM 带来的功能。当橡胶终于上路时，我不得不回去重构代码，并遵循更多经过时间考验的方式来编写查询。
90% 的时间，这些使用注解的框架运行良好，但是当这些框架失败时，您需要系统在压力下执行的那 10% 恰好是这些框架失败的时候。
现在回溯到 Spring 和 Annotations——我为什么不喜欢它们？仅仅是因为他们让我写代码就像我是一个第一次学习东西的大学生，我的教授不想让我太难。他们迫使我远离过去黄金时代的良好做法。是的，过去设置几个类需要时间，编写 SQL 查询也需要时间，但我在正确的地方有正确的东西。是的，在我们聚集动力之前需要时间，但是一旦我们正确设置了这些基础知识，我们不仅可以高速开发，而且我们拥有高性能且易于修改的代码。
是的，没有人可以强迫您这样做，但是普通的 Joe 开发人员或普通的 Jim 架构师没有时间和意愿按照我的方式制作这些系统。他们进行谷歌搜索，当他们看到 5 篇文章说同样的事情时，他们认为这是正确的做法并且他们愉快地继续。我们的许多高级技术人员也阅读了这些文章，他们支持这些设计，不同意我在本文中的观点。
TLDR；
我的建议是不要使用注释来配置您的应用程序。配置从来都不是代码的一部分——这就是为什么它们是配置而不是源代码的原因。所以让配置留在配置文件中。当客户要求更改表或值并且您告诉他们这将需要五天的开发、测试和部署时，短期内生产率的小幅提高不会有多大意义。