知识大全 JBossSeam学习系列之五--完结篇

Posted 2022-07-18 项目

篇首语：蹉跎莫遣韶光老，人生唯有读书好。本文由小常识网(cha138.com)小编为大家整理，主要介绍了知识大全 JBossSeam学习系列之五--完结篇相关的知识，希望对你有一定的参考价值。

JBossSeam学习系列之五--完结篇 以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！

　　由于前段时间使用JSF做了一个项目不少使用JSF的兄弟们对JSF评价并不好因此在学习的过程中一直在想 JSF究竟是不是应该继续学习继续研究使用下去在看完Seam In Action的第三章后这个星期又对Struts 简单学习了一下终于决定结束JSF和JBoss Seam的学习了

　　因为从JSF的学习和Struts 的学习对比中明显觉得JSF复杂对于一个技术力量不是非常强的项目组来说使用JSF当你遇到一些问题时绝对是一件痛苦的事情

　　从自己的实践中觉得JSF至少有两个致命伤

　　觉得JSF貌似把简单的事情搞得复杂化了在传统的MVC框架如Struts中从request中获取param很容易也可以将param封装为对象在JSF中希望将这一切都模型化一切都以组件为中心类似于Swing的架构但是的无状态以及web的本质使得一般JSF只能将组件树存放在服务端同时又不能象CS程序那样方便的查看组件的状态属性等信息对于通常情况来说 JSF将其封装的很好不用我们开发者操心但是当遇到一些问题时对于开发者想去调试查看问题时问题就显得很复杂了

　　 JSF的自定义组件感觉超复杂难度应该比当年自定义JSP标签更要高试想一下如果哪个组件不合意了想改一下还是比较困难的除非对JSF组件有相当的深入了解

　　顺便把项目中遇到的一个RichFaces的缺点列出来

　　RichFaces在生成组件的时大量使用了Div 曾经有过一个页面有千多行（在一个table中）页面上还有一个RichFaces的下拉菜单从而导致菜单响应非常之慢后来只有将rich datatable换为普通的 table 就没有问题了

　　再看看Seam In Action中总结的JSF的缺点

　　在JSF中初次请求的处理流程太过简单而后续请求则执行了完整的复杂的处理流程在JSF中假设第一个调用应该是在页面被渲染后执行但实际中有时我们需要在第一次请求时就执行某些操作在JSF中缺少象Struts中的Controller

　　所有的请求都是POST 浏览器处理POST请求是比较草率当用户执行了一个JSF Action操作后点击浏览器的刷新按钮时浏览器会询问用户是否重新提交这会令用户非常困惑

　　仅仅拥有简单基础的页面导向机制

　　过度复杂的生命周期

　　JBossSeam宣称对于JSF存在的缺点都提供了解决方法但是有一种更复杂的感觉

　　在Seam中生成选择的项目时有EAR和WAR的选项如果选择了EAR选项那么Seam会生成四个项目分别为war ear ejb test四个类型的项目有一次我将生成的项目从一个目录拷贝到另一个目录切换了Eclipse的workspace 此时问题来了 ejb项目提示编译错误提示无法找到某些class 找来找去找来找去……后来将项目关闭了一下再打开错误提示就没有了

　　由这个问题我忽然想到使用Seam集成JSF EJB是不是太重量级了如果采用EJB作为替代普通的POJO 对于一个小型的项目组来说一般的规模就是三至五个人（我个人的理解）开发人员本来就不多还要面对Seam划分的四个项目好像比较繁琐当然采用war模式另当别论

　　相比较而言这个星期看了一些Struts 的资料觉得Struts 的架构非常清晰易于理解

　　翻了很早之前的JavaEye上的一个帖子提到JSF是面向开发工具的如果能做到象VB那样就大有前途了年过去了不要提JSF的开发工具了就是Java各个方面的GUI开发工具又有哪个能和VB相比呢看来选择JSF作为一个方向不是一个好选择……还是及早放弃吧哎……

cha138/Article/program/Java/ky/201311/28753