当前位置:主页 > 新葡的京集团350vip正文

新葡的京集团350vip_一起听吧网进入

03月18日作者:黑曼巴


因为前段光阴应用JSF做了一个项目,不少应用JSF的兄弟们对JSF评价并不好,是以在进修的历程中不停在想,JSF新葡的京集团350vip究竟是不是应该继承进修继承钻研应用下去,在看完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中初次哀求的处置惩罚流程太过简单,而后续哀求则履行了新葡的京集团350vip完备的繁杂的处置惩罚流程。在JSF中假设第一个调用应该是在页面被衬着后履行,但实际中无意偶尔我们必要在第一次哀求时就履行某些操作。在JSF中缺少象Struts中的Controller.

2、所有的哀求都是POST.浏览器处置惩罚POST哀求是对照草率,当用户履行了一个JSF Action操作后,点击浏览器的刷新按钮时,浏览器会扣问用户是否从新提交,这会令用户异常利诱。

3、仅仅拥有简单根基的页面导向机制。

4、过度新葡的京集团350vip繁杂的生命周期。

JBossSeam传播鼓吹对付JSF存在的毛病都供给了办理措施,然则有一种更繁杂的感到。

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

由这个问题我溘然想到,应用Seam集成JSF、EJB是不是太重量级了,假如采纳EJB作为替代通俗的POJO,对付一个小型的项目组来说,一样平常的规模便是三至五小我(我小我的理解新葡的京集团350vip),开拓职员原先就不多,还要面对Seam划分的四个项新葡的京集团350vip目,似乎对照繁琐,当然采纳war模式另当别论。

相对照而言,这个礼拜看了一些Struts2的资料,感觉Struts2的架构异常清晰,易于理解。

翻了很早之前的JavaEye上的一个帖子,提到JSF是面向开拓对象的,假如能做到象VB那样,就大年夜有出路了,4年以前了,不要提JSF的开拓对象了,便是Java各个方面的GUI开拓对象,又有哪个能和VB比拟呢,看来选择JSF作为一个偏向不是一个好选择……照样赶早放弃吧,哎……

着末我感觉可以用这么一句话可以形容JSF,看起来很美,用起来不爽。

最近关注

热点内容

更多