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