posts - 176, comments - 240, trackbacks - 0, articles - 7

关于JSF

Posted on 2007-07-29 23:43 canonical 阅读(1192) 评论(7)  编辑  收藏 所属分类: 软件开发
   JSF(Java Server Faces)技术从发布时间上看已经是一种比较古旧的技术了,但是目前仍未能成为主流的开发实践。从我知道这种技术开始, 我对它的判断就与我最早对于EJB的判断一样, 它们都在某种程度上捕获了真正的需求,但是因为它们自身诡异的技术路线.我很怀疑是否这些标准制定者故布疑阵, 便如Microsoft的OLE技术一样, 故意抛出一个错误的方向, 将大批组件开发商带入死局.
   JSF技术是一种双重的存在:它首先是一种标准,然后也提供了一种缺省的实现。但是从这两方面,我都无法看到JSF的未来。
   从设计上说,强类型的视图模型对象层与Witrix的架构设计原则严重冲突。Witrix的基本架构是浏览器和后台服务器通过具有显明语义的url实现两分,这也是所谓REST风格的一种内在要求。隐蔽了链接的技术破坏了基本的web超链模型. 为了获得那么一点点结构控制能力, 做出这样的抽象是不合适的.JSF的配置模型继承了structs的传统,仍然是那样的冗长繁杂。我们是否真的需要这些配置文件,还是希望像ROR那样在代码中直接完成一切?
   不能在标准的浏览器中预览. 可以说创造了一个JSF IDE的市场, 但是这无疑是一个无聊的市场. 现在有一些备选的方案, 如Facelets, 使得jsf可以采用属性语法, 但是只要想想仅仅为了这么一点小小的修正所需要付出的开发量就足以让人崩溃。
   JSF提供了组件级别的事件响应机制,因此似乎是AJAX应用的理想场所.但从Witrix平台的开发实践来看,JSF对于AJAX的使用是受限制的,有着很大局限性的.组件事件响应并不一定要采取JSF那种体系结构.
   从实现角度上说,基于jsp tag可以说是JSF的致命弱点之一. jsp tag从设计之始就一直是未经过实践考量,其设计无法支撑复杂的控件架构. 特别是早期JSF与标准的JSP tag不能互通实际上是明显的设计缺陷, 而且性能问题是内置在该设计中的. 现在虽经多个版本的不断补救, 但是为了兼容性, JSP Tag负担过重, 它始终是基于文本处理模型,实际上不可能有什么本质性的进步. JSP tag模型过分孱弱必然造成JSF设计中大量处理过程堆叠到界面对象层,更加剧了JSF的模型复杂度和性能瓶颈。 实际上根据Witrix平台中tpl模板技术的设计经验,大量界面构建过程是可以在模板层以直观的方式完成的,而不需要借助视图模型对象。
   所有问题的一个集中体现就是增加一个新的JSF组件绝对不是一件平凡的事情.如果有一天这个问题可以得到解决,那时的JSF从思想和实现上都必然和现在的JSF有着本质性的区别.

Feedback

# re: 关于JSF  回复  更多评论   

2007-07-30 10:00 by 狂人
"从实现角度上说,基于jsp tag可以说是JSF的致命弱点之一. jsp tag从设计之始就一直是未经过实践考量,其设计无法支撑复杂的控件架构. 特别是早期JSF与标准的JSP tag不能互通实际上是明显的设计缺陷, 而且性能问题是内置在该设计中的. 现在虽经多个版本的不断补救, 但是为了兼容性, JSP Tag负担过重, 它始终是基于文本处理模型,实际上不可能有什么本质性的进步. JSP tag模型过分孱弱必然造成JSF设计中大量处理过程堆叠到界面对象层,更加剧了JSF的模型复杂度和性能瓶颈。"

请问你认为你真正理解JSF的组件架构吗? 你有真正去理解过JSF的架构设计吗?
请问JSF确实是必须基于JSP TAG吗? facelets又是什么? 是替代方案还是补充?或者说是另一种视图组织技术? JSF并非一定需要JSP为表现载体, 自然也并非一定要基于JSP Tag.

REST风格又怎么样? REST是什么时候提出来的? 正如REST提到的那样,有些表现转移是应该明确的,但时代在进步,并非所有的应用都是那样,下任何结论之前我们应该先给定一个命题的场景(前提).
诚然, JSF的导航体系比STRUTS并未进步多来,但并不代表我们不能定制其导航策略,正如SWF与JSF的协同一样.

JSF架构本身没有问题, 问题在于目前对JSF的实现上, 目前只是可用组件还不多而已,大部分都需要自己开发, 然而可喜的时,目前已经有许多商业的实现,也有许多开源的实现, 比如JBoss的richfaces, 看看别人实现的组件, 并非想象的那么重型,也并非想象中那么难用.关键看你如何用. 换句话说, 如果光颓颓地应用JSF,的确有些烦锁,但如果你能与SPRING集成起来使用,开发就会轻便许多.如果你的应用是流程式的, 可以集成SWF, 这会让你的应用更加整洁.

PS.我所谈到的这些技术并非空穴来风, 我本人已经实践了一年多了, 其实践的项目不会是你想象中的那么小.

# re: 关于JSF  回复  更多评论   

2007-07-30 12:15 by 传奇世界私服
提供多多

# re: 关于JSF  回复  更多评论   

2007-07-30 13:06 by QP
很赞同作者的观念。

这里有篇文章很有趣,一楼的可以看看:
http://blog.csdn.net/turingbook/archive/2007/06/28/1669663.aspx

# re: 关于JSF  回复  更多评论   

2007-07-30 15:17 by canonical
JSF技术有一些真正有价值的东西,但是根据我们的实践,这些价值有其他更加优雅的体现方式。 JSF不是必须采用JSP Tag, 但是它需要一种类似的技术,而它在架构设计中必然要照顾到这种技术实现。 其实witrix中的tpl技术也是一种tag技术,只是它远比jsp tag要精致。

JSF架构最大的问题就是开发新组件很麻烦,完全基于JSF构建程序很繁琐,最终提供给用户的调用接口其实也有更加简明的方式.

# re: 关于JSF[未登录]  回复  更多评论   

2007-07-30 17:52 by beansoft
下了个微软的 Microsoft Visual Web Developer 2005 速成版, 感觉 JSF 跟 ASP.NET Web Form 的确很像. 微软的组件类库很方便, 很快速, 拖放几下就可解决问题. 而且他们的设计器既能解析HTML,也能解析里面的 TagLib. 所以 Tag Lib 本身不是错, 开发组件难点很大也不是错. 微软的 IDE 已经帮你做好了所有的东西. 所以 JSF 难点就是 IDE 太差, 组件定制可以由专业厂商来做. 微软的 .NET 控件从来不鼓励程序员自己去做.

一句话, 每人都想做大自己挣钱, 才导致了这么多 Java 厂商 作出来的东西竟然还不如微软一家公司做的. 那么多框架, 很多都是垃圾. 只有组件没有 IDE 你让人手写代码来做页面?

# re: 关于JSF  回复  更多评论   

2007-07-31 11:20 by dna
JSF基于事件的开发模式与传统JAVA web开发有很大的差异,导致很多老的JAVA程序员很难适应,

还有一点JSF缺少一个像Microsoft Visual Studio强大的开发工具,不过netbeans正往这个方向努力,

# re: 关于JSF  回复  更多评论   

2007-08-13 00:31 by canonical
开发工具并不一定是生产力的主要来源

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


网站导航: