个人经验表明,对于大多数开发人员来说,处理注释比处理标准的Java XML配置要容易得多。对于像JPA和Spring测试这样的事情,它们是绝对的救星。
注释的好处在于它们使得类的配置自我记录。现在,您不必搜索一个巨大的XML文件来尝试弄清楚框架如何使用您的类,而是您的类告诉您。
通常,这种变化的问题在于习惯它需要花费时间。大多数人,包括开发人员,都抵制变化。我记得当我开始使用Spring时,前几周我想知道为什么有人会忍受与之相关的头疼。然后,几周后,我想知道我以前怎么能没有它。
这主要取决于集成开发环境(IDE)的支持。我觉得应该通过IDE中的检查来保持注解与代码同步,但是对此的支持有些欠缺。
例如,较旧版本的IDEA会在没有使用 @Override 的情况下警告你覆盖了一个函数,但是如果你更改了方法签名(或者超类签名),破坏了它们之间的关系,它并不会删除 @Override 标记。
没有支持的话,我觉得注解是一种给代码添加元数据的麻烦方式。
我绝对喜欢注解。我在Hibernate/JPA、Seam、JAXB等任何可以使用的地方都会用到它们。在我看来,没有什么比打开一个XML文件才能找出一个类是如何处理的更糟糕的了。
在我看来,注解让一个类自己说话。而且注解(希望如此)是你的IDE内容助手的一部分,而使用XML配置通常需要你自己摸索。
然而,最终可能取决于XML配置和注解在任何特定库中的实际使用方式(因为大多数库都提供两者),以及使用的注解类型。我可以想象,定义与构建相关的注解(例如文件/URL路径)可能实际上更容易作为XML配置。
我个人认为,你提到的特定用例(自动生成Web表单)是注释的一个很好的使用案例。任何一种“框架”场景,在这种情况下,你可以编写简化的代码,并让框架根据一些建议(即注释)来完成繁重(通常是重复性的)工作,我认为这是注释的理想使用案例。
我很好奇为什么你不喜欢在这种情况下使用注释,以及你认为什么是“维护负担”?(我并不是要侮辱你的立场,只是想了解它)。