首先声明：一家之言，权当笑尔。

我做web有些时候了，刚开始做.net时遇到一个前辈写的框架，一堆xml配置，配置用什么.net控件，样式是什么。一个页面用一个xml配置就出来了。哎呀我的个天，那个xml真是看着头疼啊，做梦都是xml。一个不小心配错了就报错，但是找错又不直观。动态生成的控件，无法使用vs调试。每添加个新功能还是得改代码。我当时很纳闷，为什么要这样写呢？抛弃了.net提供的优点不说，把个逻辑混成一团分不开，我好郁闷，二次开发就是这么痛！现在想一想，大概是她想保持界面风格一致吧，受够排版的苦了？这也造成了我对xml极度的反感。

后来做java,刚开始很喜欢框架，见个新框架就很激动，抱着这个action看又抱着那个action看。但是实际用的过程中比起.net组件化的架构确实要差一些，后来自己写了个框架sopo。意思是简单好用。

JSF

我最先用的是jsf,那时国内都是struts,而jsf正是刚提出来的时候，大概公司的技术领袖被sun的王婆卖瓜吹得晕乎了，决定使用jsf。我就开始jsf了，要自己开发jsf组件，开发一个还好，开发那么多我就烦了，这是什么个东西？？我要开发个组件要配置一堆xml,经常配错就报莫名其妙的错误，你根本想不到是配置造成的。哎我嘞个去，又是这个xml。jsf组件开发也是MVC模型，写个组件起码要3个类（我写个tree组件有十几个类），它还有个绘制器的概念，意思是说哎呀你写个模型可以使用不同的绘制器来展示就可以了，像手机的用手机绘制器，浏览器用html绘制器。刚开始我还蛮认同的，后来一到写绘制器就心里就窝火：你XXX的能在html上站稳脚跟就不错了，还手机的，看我以后还用不用你@#￥@#￥。还有个特点就是慢，如今jsf都这么多年了，我打开一个jsf的网站，感觉就是-----慢。也难怪，本来一步就可以做好的事情，非要拆开一二三四五六，能不慢吗？这也反映了java普遍存在的问题---学院学究，摊子太大，脱离实际！

后来换了家公司，他们也是上了jsf的套，正好找到我来救火，一看，匆匆忙忙组件都不会写，还用的richfaces。richfaces写组件还要依照他们规范来写客户端脚本。不过我倒觉得richfaces做的要好些，他的实现理念还比较创新，与ajax结合的比较好。我还发现了richfaces当时刷新请求机制的顺序问题，让richfaces的开发者改了。这家公司后来也怕了jsf，决定不再使用。

Tapestry

后来听说tapestry性能好，我就开始试用。它是基于模板的展现，但是我一直想找动态创建组件的方法，没有。看了源码，也没什么好办法实现！找资料，很少，而且我觉得tapestry4之前都比较复杂，虽然tapestry5似乎是意识到了这一点，大刀阔斧的删了很多鸡肋。但是一直没有火起来啊！用的人少，自己用的也不是很顺手。我对他的兴趣也越累越淡，弃之。

webwork

口口声声是说基于组件的，但是我想找到动态创建组建的方法，还是没有？？页面上要写组件，代码里面还是要通过id才能获得@@。晕……其他的我也不想说了，不是我想要的。

Strust2

Struts出来的早，别人用着都好，MVC嘛，简单就是美，我认同硬道理--实际用的人多就是有道理的。struts2是基于webwork2的， MVC很好，我首先自己开发标签,(开发struts2标签见我的文章 http://blog.ureshika.com/archives/71.html)。感觉不爽。

来看看广为流传的struts2的特点：

Struts2 Action有以下特点:
—  Action类完全是一个POJO，因此具有很好的代码复用性。
—  Action类无需与Servlet API耦合，因此进行单元测试非常简单。
—  Action类的execute方法仅返回一个字符串作为处理结果，该处理结果可映射到任何的视图，甚至是另一个Action。

前两点我很赞同，第三点我很痛恨，因为涉及到xml.我还要用到过导航继承，那个配置哦，配得我头都是昏的。我真搞不懂，不就是个导航吗？有必要搞得这么复杂吗？实现个页面要配置几个地方，这是个问题啊。曾经有人问我一个struts2的程序为什么那样写，就是个登陆的功能，这个跳到那，那儿再跳到远方……他看半天没看懂￥%￥%。哎---无语。

struts2还提供多种“特性”,什么多种模板语言啊，titles啊，实际你用起来，觉得完全就是忽悠人，就算是吃饱了撑着一个项目里面用多个模板语言，它实际支持的很不好，这毛病那毛病，你用了就知道。

许多细节地方我都不说了，反正我用struts2很恼火。

SpringMVC

这个和spring结合的话倒是很方便，不过它的映射仍然需要配置或者是写注释。每写个页面要写个模板，控制器，配置mapping。我比较反感的是不能省略配置映射这一步---哪那么多配置的！！不过相对于其他来说，还是比较简洁的。如果以“保持团队编程风格一致”这个理由（我可是很不认同这个观点）来说非得选个框架的话，我就会选它。

我相信许多熟手都会自己掌控住一个灵活的适合系统的框架。通过对底层几种技术的柔和应用来构建系统，而不需要这些另外的框架。毕竟，那只是个框架，它只提供了一种工具而已。