小白乱弹xml和annotation配置

以前的项目都没有用到annotation，大量的xml配置文件让所有的开发人员都有一点心寒。于是最近的一个项目大范围使用annotation的项目，虽然在项目之初，我是绝对站在annotation这一边说话的，但是随着项目的推进，慢慢的我开始体会到annotation的一些不足，甚至有些怀恋xml了。
  
因为之前团队里很多人对大量xml产生一些恐惧或者说是反感，认为大量的xml让人维护起来实在是眼花缭乱，而且由于xml里的很多配置都基本是差不多的，在复制粘贴这些配置的时候很容易忘记改掉某些地方而产生问题。所以当一些拥有annotation的框架出现在新项目选型的范围之内时，大家都十分愿意接受它。问题就这样产生了，annotation被我们当成了救命稻草，几乎只要是能用annotation的地方绝对不用xml配置。

我们采用了struts2+spring2.5+hibernate3的主框架结构。在刚开始的一段时间annotation“成绩斐然”，我们所有的xml配置文件的内容几乎压缩到比以前方式配置helloworld多不了多少的程度了。大家对这样的成果都十分的满意，于是annotation开始被我们神话了。随着框架搭建的深入，事务、日志、安全等等考虑加入其中以后我发现问题有些不对劲了。采用annotation配置事务需要到每一个负责事务的类里面去编写相关的规则，很多相似的东西都要在每个类里重复的写。而且如此讲事务控制的代码分散在类中实在是不便于管理和调试修改。此时，我开始对annotation产生了怀疑。于是改了我的qq留言，没过2天javaeye上也看到了相关的讨论。与此同事，老大也发现了类似的一些问题。例如，我们的实体上都有很多的标签去定义，这样如果开发者仅仅是想看看某个实体有什么属性，他将不得不看到一大堆的标签，而且如果我们将此实体当作一个普通的pojo使用的话，也会附带很多无用的annotation在其上。

当天下午，我通过IM向以前的一位前辈请教，我问他对于xml和annotation的看法。问为什么现在annotation如此的火爆，有些用起来并不好的地方也被滥用了。他的回答是：我最近好一段时间都没在开发一线了，具体的可能我也说不太准，可能技术人员都喜欢捣鼓新技术吧。我觉得他的话也有一定的道理。。。。。

后来我又好好的想了一想，annotation现在肯定是被我们滥用了，这个情况需要改善。那么什么时候该用annotation什么时候该用xml呢?既然这么些流行的框架都提供的annotation的方式，那他们的用意又是什么呢？我还有几点疑惑：

1.用annotation配置难道不是配置吗？我们以前是害怕大量的xml，难道我们就不害怕大量的anntation吗？xml还是在一个地方管理，annotation散布在类中，如果后期发现前期一些设定不合适，例如事务等等，难道还跑到每个类里去修改吗？

2.用annotation注释spring管理的bean，如果我们忘记写annotation或者我们写错了，那么只用在运行代码的时候（可能是测试用例）才能发现这些问题，并且还可能打开多个类去检查。而xml的配置一般都是集中在一起便于检查，而且也只打开一个xml文件。

3.我们为什么要配置？我认为配置的初衷就是为了方便更改可配置的项，方便统一管理。换句话说就是从代码中抽出可能的变化。既然是这样，那么annotation把配置信息分散到类中的行为岂不是有为这个初衷？

由于有了这些疑问我自己都不能给自己一个很好的解释，所以我在google上又搜索一些关于xml和anntation的讨论。发现有一些观点还是不错的。

有一种说法就是java语法过于对象化，以至于很多操作调用的过程规规矩矩过于繁琐，annotation是sun为了弥补这样的情况提高java语法的功能而产生的产物。所以annotation应该用于加强java语法的地方而不是用在做配置的方面。例如在action里通过annotation来简化传递参数的过程等。我觉得还是比较合理的解释。

还有一种说法就是认为annotation适合于稳定的建模过程中，用于那些不易更改的对象。提高内聚，认为这些行为本来就属于模型本身。这个我也基本同意，只要是这个模型或者实体不用于其他方面，职责单一的情况下是比较合理的说法。

既然看上去xml并没有什么不好，那么大家为什么有些反感xml呢？
一个好几千行的xml确实让人眼花缭乱。我觉得首先是xml划分要合理，如果比较多一定要细分模块的配置文件，让模块内的配置尽量的少一些，看起来比较舒服。
其次就是xml配置项中有很多看起来都重复的地方，这个可以通过泛型通用类去解决一些只有CRUD相关操作的类的配置，可以大大减少配置文件的大小和重复性。又或是充分利用一些新版本框架对通配符的匹配来减少相似配置的出现。

最后总结一下，目前看来annotation和xml谁是谁非似乎还没有一个完全让大多数人信服的说辞。希望随着实际应用的增多，最后能有一个让大多数人信服的最佳实践产生。也希望自己在当前的项目中，进一步的对这2者的进行更深入的理解比较。实践才是检验真理的唯一标准啊。

评论

5 楼 bulargy 2008-12-08  

taupo 写道

我们的项目也是xml+an
用了an是要比以前纯xml方便多了，不过我还是觉得xml有不可替代的作用
两者结合比较好，纯an或者纯xml都是病态的想法，任何事情都要有个度

我现在采用的方式是，如果配置上既提供服务又利用别人服务的就用xml(比如service、dao层)
在配置上只用接收别人服务的就用annotation(比如shh结合时候的action层通过struts-spring插件可以不用显式的配置action层，那我在action层注入service的时候就用annotation)
感觉这样配置上方便一点。

4 楼 taupo 2008-08-31  

我们的项目也是xml+an
用了an是要比以前纯xml方便多了，不过我还是觉得xml有不可替代的作用
两者结合比较好，纯an或者纯xml都是病态的想法，任何事情都要有个度

3 楼 bulargy 2008-04-06  

还有你说aop的问题，spring2.5的aop都可以用annotation写的。。他们正是用annotation来做的。。。我指的是这点。。。
struts2确实我觉得还算是在配置方面做的不错的，很多惯例和那些通配符的使用很强大。

2 楼 bulargy 2008-04-06  

你误会我的集中管理的意思了，我的意思就是按照模块来划分xml来“集中”管理，一个功能模块内的bean都在一个xml里，这和annotation散布到每一个类里配置相比也可以算的上“集中”了。

1 楼 feigme 2008-04-06  

annotation是很不错，但是不能因为追求新技术而一味的全部替换

引用

采用annotation配置事务需要到每一个负责事务的类里面去编写相关的规则，很多相似的东西都要在每个类里重复的写。

譬如这个用AOP就很好的解决你的问题
struts2采用package的方式来管理，对团队分工协作比较方便
对于大项目来说，集中管理那些文件眼睛视力肯定会瞬间下降的
相对来说我倒是比较偏向于按function功能或模组来管理配置文件