为什么主流Java MVC框架如此难以使用 框架MVCJavawicketJavaScript

使用J2EE Web开发已经好几年了，从JSP、Struts、WebWork到现在的Struts 2、Wicket，没有一个用起来简单顺手的。

无论哪个框架吹嘘自己有多么简单和高效的生产力，甚至让一个从未接触过Web开发的人5分钟能上手，绝对是骗人的。照着教程做一个Hello World还可以，一旦网站规模一大，根本无法维护。

再深入挖掘一下，你会发现，其实一个MVC框架无论服务器端设计有多么差，其实也差不到哪去，有面向对象经验的开发人员都可以写出比较能维护的代码，即便像Struts这种比较古老的框架，服务器端开发也不难，和WebWork2比仅仅是不方便而已。

但是到了View这一层就五花八门了，总体来说，有以下几路主流门派：

1. 以Struts为代表的JSP + Tag派，真叫一个难用，尤其是Tag，不但要查手册，你还必须写出if equals ... else的逻辑来。

2. 以JSF为代表的全Tag派，基本上写一个JSP和一个XML没啥区别，都是Tag堆出来的，甚至变态到HTML元素都给Tag了，比如<h:div>。

3. 以Wicket为代表的嵌入式派，可以通过<span wicket:id="message" id="message">来搞定，不破坏HTML，不过通过Filter过滤性能值得怀疑。

无论哪种MVC框架，目的都是要简化View的开发，然而在实际使用时却发现，简化了简单的页面，复杂页面却变得更复杂了，因为这些MVC框架都普遍忽视了一个基本原理：现代Web技术是建立在HTML+CSS+JavaScript基础上的，任何试图帮助Java开发者隐藏HTML、CSS和JavaScript的努力最终都将阻碍Web开发。不会HTML，不会CSS，不会JavaScript，那就不要做Web开发，无论你多么精通Java！

正是由于这些MVC框架有意无意地让Java开发人员远离HTML，才造成了View开发的困难重重。尤其以JSF为代表，性能就不说了，要添加JavaScript你只能先看编译后的HTML源码，要修改CSS要DEBUG至少N次，所有的可视化HTML编辑器都用不了。

所以，要真正提高Web开发的生产力，尤其是页面的可维护性，Web页面必须由精通HTML+CSS+JavaScript的开发人员完成，服务器端技术对这些的侵入性越小，页面越容易维护。目前我认为比较好的View框架还是Velocity和FreeMarker，通过<div>${message}</div>比JSP Tag强很多，结合HTML可视化编辑器（主要指Dreamwaver），调试起来非常方便，而且不用重启服务器。至于服务器端，其实各MVC大同小异，我一直使用Spring MVC+Velocity，少集成一个框架毕竟麻烦少一些。