xml和annotation的是是非非

/**

*作者：张荣华

*日期：2008-4-2

**/

前言
Xml和annotation都是我们在项目中常用到的技术，尤其是在配置文件这一块。很久很久以前，当jdk5.0还没有出来的时候，或者我们还没有大规模换到jdk5.0的时代，xml作为配置文件是大行其道，但是当annotation诞生之后，形式有所转变，曾经发挥巨大功能的xml开始被人们所批斗了，现下人们对annotation开始了疯狂的崇拜。

那么就先说说xml的功与过，他的功我们都看在心里，就拿以前最常见的技术来说吧,struts+spring+hibernate，哪一个不用配置文件，使用配置文件谁不用xml，虽然hibernate还支持property文件配置，但是很显然，那玩意儿更不易读（可能还有人说，我用xdoclet了， 可是这个东东用的人是非常之少的）。于是我们看到我的项目里到处都是xml配置文件，从struts，到hibernate，而且尤其是struts和hibernate，一个中型项目，struts的xml配置文件有时候达到数万行，再大一点的，可以数十万行，虽然很多时候都是拷贝，粘贴，但是看这个这个数十个几千行的struts配置文件能不让人倒胃口吗。再说那个hbm.xml，大家再熟悉不过了，你想想吧，一个几域模型的项目里，你需要有多少配置文件，我眼睛都看花了。这些都是xml的缺点。但是xml也有优点，比如我要做一个通用的配置，象spring里的声明式事务管理之类，那么所有的需要事务管理的bean，我只要一段配置文件或者很少几段配置文件就可以解决，这个配置不会超过50行。

那么再看看配置文件界的后起之秀吧，话说自打annotation出来之后，众人犹如众星捧月一般，把这玩意举上神坛，每日供奉，于是呼出来一批基于annotation的mvc框架，我们看看最常用的一个吧，struts2.0里也可以使用annotation来实现result的配置，我们看看它是怎么做的：
首先：指定action的package目录。
其次：根据上面指定的目录下的action的名字来声明url，这样struts2.0可以根据url自动找到需要执行的action的方法。
第三：根据方法上声明的annotation来返回对应的页面。

Struts2.0的这个零配置就是使用coc和annotation来实现的，很简单吧，但是虽然简单，功效却非常之大，这样struts.xml中的action的配置全部都可以拿掉了，配置文件就会变的非常之简单。然后我们在维护或者开发的时候，第一时间就可以知道这个方法会返回哪些页面（曾经我在webwork2上也实现了同样的功能），而在从前，我们不得不去xml配置文件中ctrl+f来寻找，就这一点就节省了很多的时间，同时xml配置文件中的配置也所剩无几，剩下的都是一些公用的配置。我们再看hibernate呢，hibernate3.2支持annotation，而且在新项目中我一直使用annotation来配置我们的po，我们得到的好处就是我们再也看不到hbm文件了，我直接就可以看到某个po属性的配置，可以这么说在这个地方用得是恰到好处，给我们带了不少方便。问题是annotation是万能的吗，我需要把struts.xml文件全部去掉吗，我要把事务的配置都写道类里面去吗，如果我们这样做了，我相信实现annotation的人一定会哭了。

举个例子吧，spring2.0支持使用annoation来配置事务，我看了一下，发现如果我们用annotation来配置事务，事务的传播途径，是否只读之类的配置我们需要写上很多遍才行，而事实上，大多数方法的事务需求是一样的，即使有一些不一样，我们也可以通过多配两个transactionAttribute就可以实现，我们为了使用annotation而让配置反而变复杂了，值得吗。难道只是为了和别人吹嘘“hi，知道吗，我们现在连事务也使用annotation来实现了”。我们最想要的不是把这些公用的东西整到annotation里去，而是要把一些独用的东西放进去，比如说struts中的action定义，hibernate中po的配置，还有一个目前最想要的是spring的bean定义，这些东西可以放到annotation里去。

Annotation不是万能钥匙，不能解开所有的锁，大家也不要对它过度崇拜，一个优秀的软件工程师不只是不断的学习，更需要的是正确的判断在何种场景下需要选择何种技术，一般说来一种技术越强大，那么它的局限性就越高，所以通常我们会选择其他的技术来和它互补，在配置文件界，我们可以说annotation很好很强大，但是我们不要忘了xml也是很好的，也是很强大的，而且他们是互补的。

 

零配置不是annotation的功劳，早在struts2还叫webwork2的年代，照样有零配置的方法可以使用。
偶一直认为把annotation当作配置来用是一点好处也没有的，偶在实际项目中见过Model一个field上挂了O/R Mapping, Full Text Index, Validation, Security...整整超过10行的annotation，偶只不过是想看看这个Model有什么field而已，这样把整个一大包乱七八糟的annotation都塞在一个文件里面，不是一个大倒退么？

struts2.0默认的零配置是用过coc和annotation来实现的，如果是struts2.0+codebehind的话，那么这个零配置就只是通过coc来实现的，但是我觉得result也用coc来实现太不直观了，所以我倾向用annotation来实现result的配置。

Model一个field上挂了O/R Mapping, Full Text Index, Validation, Security...如果这么多配置不放在annotation中还是需要放在配置文件中，那么一个model就需要很多配置文件了

偶的意见就是要分开多个配置文件，减少Line Of Code per File，减少维护成本，降低出错概率，分离关注点。

annotation还是有很多方便的地方,struts2中数据验证我更喜欢annotation,action配置我还是用xml
也自定义了一些annotation,比如model的属性加@NotInCopy复制属性的时候过滤,@NotInJson生成json的时候过滤,action的方法加@Captcha表示需要验证Captcha,加@PostMethod表示这个方法只接收Post请求.

我现在的原则是，能不用Annotation的地方尽量不用，能不用XML的地方尽量不用。两者皆可时，看哪个需要敲的字母少，扩展性更强。

某个Annotation受到欢迎的程度我觉得取决于两点，一个是Annotation是否足够简单，例如像Spring2.5中的@Service,@Autowired。另外一个，就是如果有相应的XML配置，是否能完成“弱智”过度。我这里所说的弱智过度其实就是指Annotation中的语义是否能够和XML中的属性语义保持一致，以至于那些原本从XML过度到Annotation的朋友可以很容易的就切换过来。这一点，Struts2的Annotation就做得比较好，但是Hibernate的Annotation就很不容易让人产生联想。

事实上，我个人很反对在一个Domain Model上加Annotation来完成类似持久化、搜索等语义。就像Readonly说的，一个Domain Model就是一个Domain Model，很多情况下，我需要在其中填充一些业务逻辑，或者甚至我只想看看有那些字段。加上了过多的Annotation，导致这个文件臃肿不堪，也搞不清楚它到底承担了多少责任。甚至还要因为某些Annotation增加很多不必要的工作量。比如，没事情在Domain Model里面加了一个额外的getter方法为了前台显示用，结果为了Hibernate还要搞个恶心的@Transit的annotaion。实在是不能让人接受。。

还有最烦什么零配置,难道Annotation就不是配置?

强烈赞同对Domain Model分开配置文件进行关注点分离。

如果只算上mapping的， 还是比较简单的。这也是楼主说的不论搞什么技术，都不要太过火，方便了大家就是好的。

我倒是觉得Result用CoC才直观而简单，annotation太繁琐，没事情多加了一句代码。

codebehind或者smarturl的插件唯一的问题就是不支持多种Result，这个另我很郁闷，需要Redirect到一个Action，CoC就无能为力了。

我最近在构思一个利用ResultCode进行CoC的Struts-plugin，完成了我们可以交流一下。