ActionForm顶我的肺

Struts老了，在这个web框架泛滥的年代里，他开始越来越不被人关注了，追溯起来他的历史要比我当程序员的历史还要远上一年半载。我走到现在，也完全是依赖于对他的一知半解才没有被IT的潮流所淘汰。但现在，他老了，他正在淡出历史的舞台。在他身后，JSF，Tapestry,WebWork等等一批新生代web框架都在对他虎视眈眈，另一方面他又受到Asp.net，ROR,Django等其他语言框架的围堵，用苟延残喘来形容Struts的现状，应该不为过。

在这个时候，对，在这个市场份额激烈争抢的时候，Struts当然不会坐以待毙，2.0的推出又让众多Struts粉丝们对其报以众望。事实是什么呢，事实仅仅是Struts合并WebWork后，在其基础上推出的一个产品，我不同意Struts2.0与Struts1.X是完全两个不同产品的这一观点，这不仅仅是因为他完全兼容1.x，而且在于他的编程理念事实上和1.x是一致的，只不过换了一个实现手段而已。当然，从1.3升级到2.0，其中Struts自己的新技术寥寥无几，核心机能都是WebWork的，从另一方面看，Struts这层皮是多么的值钱，也是可想而知的。

说到这，该往题目上靠一下了，ActionForm是什么？他是画面数据的载体，他是MVC中的M，他是javabean，他是值对象VO。我们为什么要使用它，因为我们要将页面的数据传到后台，也就是从表示层传到逻辑层。ok，我们现在知道了ActionForm也知道了ActionForm是干什么用的，那么我要告诉你，ActionForm正在被广大java应用框架们所抛弃，WebWork没这个概念，JSF没这个概念，ASP.net之类的就跟没这个东西了。而现在，Struts2.0也将它扔掉了。大多数人津津乐道于将pojo直接传递到画面，因为这会节省很多coding time，也提高了编程效率。当然我也很乐意省掉那些将VO与POJO倒来倒去的那些麻烦的事情。Struts2为每一个请求产生一个Action实例，这使得在Action中便可以定义画面上的众多属性，所以他抛弃ActionForm也是理所应当。

但是，我想说的是，Struts将ActionForm类取消这没有问题，但是千万不能将ActionForm这个概念所抛弃。

首先，从颗粒度这个角度来说，从Struts诞生之日起，他就不是一个颗粒度特别细的一个框架，他不能像JSF那样将眼光放在画面项目上，而是着眼于整个画面来考虑问题，那么一个画面的值对应到一个VO，那他就是ActionForm，从这个方面来说，颗粒度定位于整个画面的框架，他都应该有一个ActionForm的概念。那么我们在实际的应用框架搭建中，就应该注意这个问题。

其次，将POJO即DTO直接与画面绑定不利于大规模开发，这个问题在JSF等UI框架中也比较突出。我们要回忆一下MVC的原则，就是要为项目分层，为程序员分工，这在一个大型项目中尤为重要，这样做可以极大的提高开发效率。我希望我的开发人员都是产品流水线上的一环而已，他们只需关注与自身业务相关的工作，即扭螺丝或者是焊牢一根二极管，表现在实际项目里，就是做UI的人不需要去关注DB，作DB的人不用操心画面的实现，他们各自负责看管自己的对象。

第三，在Action定义中多属性，那么没人喜欢去读这样一个乱哄哄的文件。我们将ActionForm里的属性都取出来，然后将他们都放进了Action或UI，然后还要在这些文件中写入一些动作方法，如果画面的项目少一点你还能够忍受，如果多了一点呢？我认为这不是一个优雅的办法。我宁愿去看两个功能突出的类，也不愿去看一个混乱无章的东西。

最后，关于入力项目的校验。WebWork的那一套配置属性文件式校验的确很精彩，但那仅仅是对于简单的入力项目而言，遇到比较麻烦的校验还是需要在Action中进行，既然如此，那还不如在Form里的Validate方法中进行来的实在。

基于以上观点，我始终是ActionForm这个概念的拥簇。ActionForm对于Struts来说，确实需要变化，应该让他变得更强大，而不是去把它去掉来达到一了百了的效果。一方面我们可以让他变得更动态一些，一方面我们可以简化getset方法，另一方面还可以加强其对内部对象的操作。而从更深层次来说，我是一个multilayer主义者，我更重视的是整个项目的开发效率。

众多框架孰优孰劣其实并不重要，重要的是他是否适合我们自己的项目，是否能提高我们的生产力，而不是炫耀那些时髦的技术。