java尾行注释有什么不好

java尾行注释有什么不好_注释不好吗？

java尾行注释有什么不好

那天，我在有关Spring XML与注释的文章中运用了自己的原则，轻松进入了这个主题。对于目前正在编写此新应用程序的团队来说，这种简单的输入方式也是我不使事情复杂化的方式，该应用程序的生产寿命可能为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线程。很好，他们都解释了如何使用，但是很快我们意识到，但是在代码中使用这些所谓的基于Rich Annotation的配置，我们已经淡化了代码/设计应该是的总体含义。当我必须尝试一些新的事物作为个人宠物项目以快速起步时，这种编程风格非常有用–我可以编写一堂课，键入一些注释并Swift做好准备进行CRUD的准备，但这确实有效在企业级应用程序中，尤其是我们如何在生产中进行管理。

这些文章不过是一堆希望我们使用这些框架和新功能的市场营销/销售推销，但它们几乎没有将我们在大型生产系统中必须处理的复杂情况置于上下文中。

在2007年，我们在项目中广泛使用了Hibernate模式（带有基于XML的Spring 2.x配置），很快我们意识到，我们已经将ORM框架超越了它的范围。我们遇到了复杂的查询，试图将其改编到Hibernate中，并且有可能在MS-SQL中将其作为优化的过程来编写，而消除这些查询现在正成为主要瓶颈。我刚接触过该框架，但更重要的是，我的技术领导力推动了Hibernate的全面使用。这些人可以访问我之前分享的文章，这看起来很可行，但是他们不过是销售Hibernate和ORM带来的功能的营销材料。当我遇到麻烦时，我不得不回头去重构代码，并遵循良好的旧查询编写方法。

这些使用注解的框架在90％的情况下都能很好地工作，但是当这些注解失败时，您需要系统在压力下执行的那10％正是

现在回溯到Spring和Annotations –为什么我不喜欢它们？仅仅是因为它们使我像在学习某个东西的大学生一样编写代码。他们迫使我摆脱过去黄金时代的良好做法。是的，它过去需要花费一些时间来建立一些类，还花费时间来编写SQL查询，但是我在正确的地方放置了正确的东西。是的，我们花了很多时间才能蓄势待发，但一旦我们紧紧设置了这些基础知识，不仅可以提高开发速度，而且还可以正确地完成事情。

是的，没有人可以强迫我们，但是普通的Joe开发人员或普通的Jim建筑师没有时间和意愿来制作这些POV，他们在Google上进行搜索，当他们看到5篇文章说同样的话时，他们以为是做正确的事，他们会快乐地前进。我们的许多高级技术人员（也阅读这些文章）都支持这种设计，并且很多时候都在挑战我要在此处提出的观点。