由于前段时间使用JSF做了一个项目不少使用JSF的兄弟们对JSF评价并不好因此在学习的过程中一直在想JSF究竟是不是应该继续学习继续研究使用下去在看完Seam In Action的第三章后这个星期又对Struts简单学习了一下终于决定结束JSF和JBoss Seam的学习了
因为从JSF的学习和Struts的学习对比中明显觉得JSF复杂对于一个技术力量不是非常强的项目组来说使用JSF当你遇到一些问题时绝对是一件痛苦的事情
从自己的实践中觉得JSF至少有两个致命伤
觉得JSF貌似把简单的事情搞得复杂化了在传统的MVC框架如Struts中从request中获取param很容易也可以将param封装为对象在JSF中希望将这一切都模型化一切都以组件为中心类似于Swing的架构但是http的无状态以及web的本质使得一般JSF只能将组件树存放在服务端同时又不能象CS程序那样方便的查看组件的状态属性等信息对于通常情况来说JSF将其封装的很好不用我们开发者操心但是当遇到一些问题时对于开发者想去调试查看问题时问题就显得很复杂了
JSF的自定义组件感觉超复杂难度应该比当年自定义JSP标签更要高试想一下如果哪个组件不合意了想改一下还是比较困难的除非对JSF组件有相当的深入了解
顺便把项目中遇到的一个RichFaces的缺点列出来
RichFaces在生成组件的html时大量使用了Div曾经有过一个页面有千多行（在一个table中）页面上还有一个RichFaces的下拉菜单从而导致菜单响应非常之慢后来只有将richdatatable换为普通的htmltable就没有问题了
再看看Seam In Action中总结的JSF的缺点
在JSF中初次请求的处理流程太过简单而后续请求则执行了完整的复杂的处理流程在JSF中假设第一个调用应该是在页面被渲染后执行但实际中有时我们需要在第一次请求时就执行某些操作在JSF中缺少象Struts中的Controller
所有的请求都是POST浏览器处理POST请求是比较草率当用户执行了一个JSF Action操作后点击浏览器的刷新按钮时浏览器会询问用户是否重新提交这会令用户非常困惑
仅仅拥有简单基础的页面导向机制
过度复杂的生命周期
JBossSeam宣称对于JSF存在的缺点都提供了解决方法但是有一种更复杂的感觉
在Seam中生成选择的项目时有EAR和WAR的选项如果选择了EAR选项那么Seam会生成四个项目分别为warearejbtest四个类型的项目有一次我将生成的项目从一个目录拷贝到另一个目录切换了Eclipse的workspace此时问题来了ejb项目提示编译错误提示无法找到某些class找来找去找来找去……后来将项目关闭了一下再打开错误提示就没有了
由这个问题我忽然想到使用Seam集成JSFEJB是不是太重量级了如果采用EJB作为替代普通的POJO对于一个小型的项目组来说一般的规模就是三至五个人（我个人的理解）开发人员本来就不多还要面对Seam划分的四个项目好像比较繁琐当然采用war模式另当别论
相比较而言这个星期看了一些Struts的资料觉得Struts的架构非常清晰易于理解
翻了很早之前的JavaEye上的一个帖子提到JSF是面向开发工具的如果能做到象VB那样就大有前途了年过去了不要提JSF的开发工具了就是Java各个方面的GUI开发工具又有哪个能和VB相比呢看来选择JSF作为一个方向不是一个好选择……还是及早放弃吧哎……
最后我觉得可以用这么一句话可以形容JSF看起来很美用起来不爽
