随笔-75  评论-193  文章-5  trackbacks-0

    由于前段时间使用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,看起来很美,用起来不爽。

posted on 2008-12-25 23:35 The Matrix 阅读(2191) 评论(6)  编辑  收藏 所属分类: JBoss Seam/JSF

评论:
# re: JBossSeam学习系列之五--完结篇 2008-12-26 10:57 | fool
jsf高效省事 仅仅值绑定这一条就比struts2,struts强得太多
当然学习曲线的确比较陡 另外各开源的jsf实现并不按sun RI参考实现的方式做组件,自定义组件确实难度大了点,学习诸如ADF之类就更麻烦了
不过我还是喜欢jsf,很好  回复  更多评论
  
# re: JBossSeam学习系列之五--完结篇 2008-12-26 12:05 | The Matrix
@fool
确实JSF的值绑定比较好用,但Struts2中的值绑定我简单看了一下,发觉也没有比JSF差太多,能否明确指明JSF的值绑定强在哪里,呵呵  回复  更多评论
  
# re: JBossSeam学习系列之五--完结篇 2008-12-26 22:24 | Lf0x
没有什么技术是完美的,敢问Struts 2 能胜任所有的项目吗? 才看了一周就能完全对另外一种技术做这样的否定未免也太绝对了吧? 虽然还没接触 Struts 2 ,但是个人觉得 JSF 不差,况且企业级的开发并不是就局限在 Web 这个范围呢的,JSF 有其自己的生存空间  回复  更多评论
  
# re: JBossSeam学习系列之五--完结篇 2008-12-27 14:48 | yuanyc
兄弟,服务器端组件模型有其优点..jsf 确实是过于复杂
建议你看看wicket..既实现了服务器端组件模型的优点,又比较简单..
没有xml 配置文件, 没有标签库,只要html 模板和java代码即可..  回复  更多评论
  
# re: JBossSeam学习系列之五--完结篇 2008-12-27 16:16 | The Matrix
@Lf0x
     说的不错,没有什么技术是完美的,Struts2不能胜任所有的项目,JSF也不能胜任所有的项目,任何东西都是相对的,没有绝对合适的事情。
     JSF我并不是看了才一周,我们用它做了一个开发框架,包含了基本的权限管理及相应的用户管理等基本功能,然后有三个项目使用了这个开发框架(我负责了其中的一个项目)。但是相关项目组的兄弟们对JSF反响并不是很好。
     本来我打算沿着JSF这条路继续走下去,所以打算继续研究JSF和其相关的技术,对这个开发框架继续改进,但是研究了一段时间后,又看了Flex、Struts2后,觉得JSF确实比较复杂。而从web技术的发展方向来看,RIA肯定是重点。所以才对JSF有了动摇。
     因为我觉得JSF既然不是以后web技术演进的重点方向,又不是很好用,那么何必还让好多人在它上面花费时间呢。
     感谢yuanyc的建议,我有空再看看Wicket。
     以后可以做这个试验,用JSF、Struts2、Wicket对实现常用的功能进行一下比较,看看哪个最合适,呵呵。
  回复  更多评论
  
# re: JBossSeam学习系列之五--完结篇 2009-01-06 17:28 |
刚刚完成一个项目,客户端是Applet开发的,服务端 WEB-ESB-EJB,其中ESB做到了对EJB->EJB,SOAP->EJB,SOAP->SOAP,和EJB->SOAP的调用,其中EJB包括本地和远程两种情况。

就客户端开发技术,我觉得有实力的公司还是采用Applet。首先表现力很丰富,使用了签名后就相当于本地应用程序,功能极为强大;其次本来就有丰富的swing控件,当然本地数据集控件支持SOAP需要新开发(本人开发的,哈哈)。这样客户端开发人员其实就是做SWING的客户端开发,效率不是盖得。

前后台使用SOAP交互,扩展很方便。  回复  更多评论
  

只有注册用户登录后才能发表评论。


网站导航: