JSF 与 "我的伟大发明" ---- 关于B/S UI开发的胡言乱语

这篇帖子后面的回复和讨论 已经变得比主贴本身更值得一读了
希望读这篇帖子的朋友 有时间的话可以看一看后面的那些评论

我不希望这种技术讨论沦为口才的较量 ,所以我本人不会在发表什么观点了
但是我的"关于B/S的解耦性 以及UI层的可独立性"的观点不会改变.

=============================
此文是 "初看jsf后的胡言乱语"http://fins.iteye.com/blog/181093 一文的延伸
同样是在我对JSF知之甚少的情况下写的, 如有不当,请见谅


先来看看一个"我的伟大发明":

汤匙用来喝汤,刀子用来切牛扒. 多麻烦啊. 我设计了这样一个东西:
一头是勺子, 一头是刀子, 这样餐具就可以少一件了, 为我们的采购 摆放 整理 清洗, 提供了极大的方便.
相信不久的将来,这样的产品一定会彻底的淘汰掉现有的汤匙和刀子.


什么?你早想到了? 哦 那好吧 算作"英雄所见略同"好了.

========================================

我的伟大发明说完了, 该说说JSF了.

以前写过一篇文章:
"世上没有B/S系统,只有B系统和S系统"http://fins.iteye.com/blog/123265.

当时对jsf一点也不了解 所以没有谈及更多
(那篇文章里说的更多的是 错误的---我眼中的错误的---使用ajax 所引起的一些我的思考)

但是现在看看 用那篇文章里的观点来表达我对jsf的态度 也许会更合适.


我写那篇文章被很多人说是"标题党,唱高调"
其实 我真的希望我的那篇文章是"标题党,唱高调", 因为那就说明,我所说的已经是废话,已经是尽人皆知的事情.

但事实恰恰相反.有太多太多的人 依然固守着传统的桌面开发模式,并且企图把这种模式强加到B/S系统中.
希望用一种语言 一种模式 来解决B/S里的所有问题.
这种想法是好的, 但是那是多么多么多么的不现实啊.
和前面提到的"我的伟大发明"是多么多么多么的相像啊.


我承认java很好很强大, 它有如下优点:...(此处省去四万五千六百七十八个字)
但是 但是 但是, 他那四万五千六百七十八个字才能说完的优点里,偏偏不包括 编写web-ui.


而jsf 就是要利用各种手段,来让java去做它本就不擅长的事情.
用java费了 九百头犀牛二百只华南虎的力气(简称九牛二虎之力) 做出来的事情,
换作别的语言来做,也许只要九只蜗牛二只壁虎的力气(简称九牛二虎之力) 便能搞定.

引用

用java来生成html+js+css层面的东西, 然后用java来处理发生在 html+js+css层面上的事件.
怎么可能比在html+js+css层面内部做这件事 更好呢??

关于jsf的ui层的实现有多么拙劣 我就不多说了,
如果有哪位能找出一个做的很好的 效果比ext  qooxood dojo 之类的更好的东西请告诉我.
那些商业的 大公司 用jsf做出来的东西 什么 ICEfaces  RCFaces  RichFaces ... , 在ext面前, 你们不觉得你们的face很红吗?


也许有人会说
JSF也可以和EXT dojo相整合啊 JSF UI也是解耦的 可替换的啊,
如果一个产品能够整合一个优秀的产品,那么到底是这个产品优秀 还是被整合的优秀?
而且整合还要看成本呢,
用jsf完全的封装ext有意义吗 有必要吗 有完美的实现吗? 封装出来的东西还具备ext原有的灵活吗?

关于jsf的"可替换", 这里我们要弄明白一件事, ext可以换成dojo,我们就能说jsf的ui层是高度解耦了?
jsf在封装ext的时候,肯定要写很多标签啊 java类啊, 那些东西也是 jsf 的一部分.
我把ext换成dojo, 那些为ext封装的标签啊 java类啊还能用吗???




也许有人会说:
UI组件只是JSF的一部分, 并不是JSF的全部. JSF还有很多 例如:某某模型,某某规范,某某架构,某某机制....
一味的批评JSF的UI, 从而否定整个JSF的做法是错误的


但是 但是 但是 JSF UI这部分和JSF的其他部分---那无数个"某某"----完全紧密的结合在一起,
没有UI的JSF,根本就毫无生命力,根本就不再是一个可运行的框架,
而JSF UI孤立的拿出来, 也根本就不是一个能被称为UI的东西.

所以,我怎么可能单独的去评价JSF的ui?怎么可能脱离JSF UI单独的评价JSF身上UI以外的东西??

引用

如果有一天JSF火了, 有人跑来跟我说, 看,现在是JSF的天下了.
那么我敢保证, 那时候的JSF肯定和现在的大不同, 也许只是名字未变而已.

我再表达一下 我的观点(可能过于理想化):

引用

在B/S系统中
UI层与系统其他层面的东西的唯一联系应该是"数据"
UI层应该是在后台系统不变的情况下可切换的

总之两个字"解耦".

任何违背这个准则的框架我都不认为是好的框架. JSF WICKET DWR 都不是.
事实上,我不认为有哪个框架 可以同时做好 后台和前台两个层面的工作.
既然做不好 那就别做.

整齐划一是好的,但是 我们应该 必须 一定 永远都要承认"分工"的存在.

最后问个问题:

你见过哪个西餐厅会放一把万能的瑞士军刀在餐桌上吗?
如果没有 那好, 请你也不要指望在 B/S系统开发领域内 见到一个万能的"瑞士军刀",
至于那个"我的伟大发明"你更是可以完全忘掉它了.

评论

19 楼 fins 2008-04-11  

其实我特想听听俞司令的观点

"JSF在IDE的辅助下,可以实现快速开发",除此之外在B/S应用开发中,JSF还有什么亮点呢?

我一直认为,挺JSF贬纯浏览器端UI框架的人一般都是对ajax等技术不了解(或自认为自己很了解),所以他们的话我一般都不会听进去(这点我很不理性不客观, 我的错 我承认)

而俞司令是我印象中少数的 对这两个领域都非常精通的人, 他的话肯定对我有极大的说服力
只是我不是JSF领域内的专家, 不知道俞司令会不会理我


我下面的观点,有错吗? 错在哪呢? 其实我对自己也充满了怀疑

引用

在B/S系统中  UI层与系统其他层面的东西的唯一联系应该是"数据"
UI层应该是在后台系统不变的情况下可切换的

一个B/S系统中 应该有两个框架 一个负责s端 一个负责b端
三个太多 ,一个太少, 两个刚刚好

18 楼 fins 2008-04-11  

casazaft 写道

JSF是java走向RIA 时代的必然一步，所谓RIA(富客户端),其实说简单，就是web的体验要达到或者接近桌面程序的效果，同时还能要支持多种客户端:pc pda 智能手机....说的简单，做起来就难了，MS、Google、Adobe、Sun都想争抢RIA的王座 ,jsf只是java世界的一步旗子罢了，JavaFx是它的一个兄弟，二者的结合代表了java在RIA世界的表现。
RIA时代，程序越来越复杂了，按照经验，组件化和工业化才能应对新的软件危机，因此无怪乎JSF之流都是组件化的庞然大物，它们是设计给下一时代的...未来的十数年。

很多人认为RIA是B/S的替代者,但是我觉得不对
C/S B/S RIA 他们将会共存.
三者之间是并列的, 如果JSF是为RIA而生, 那么我希望他放弃在B/S领域内兴风作浪的年头. 老老实实的修炼自己,等10年后再出来丢人

17 楼 jianfeng008cn 2008-04-11  

我同意fins的观点 b端我用ext感觉很好，但是s端目前还比较麻烦 用json-lib+hibernate+ struts2 本来想使用dwr将java转化成json，主要是看重他的配置文件，不料这家伙也非得生成js文件，所有的demo都是在页面嵌入他的js和他生成的js。我承认我编程菜，但我还是要糊口啊，总不能等到我能写jdk了再让我正式做事吧！

16 楼 打倒小日本 2008-04-10  

JSF缺点是不少 但因为RichFaces/SEAM等项目我还是很看好JSF技术的
用JSF进行开发 感觉很好

15 楼 myy 2008-04-10  

我也很同意fins的观点。

事实上，我本人对JSF就一直“鄙而远之”。

14 楼 a3mao 2008-04-10  

我很同意fins的观点。我们项目组就为开发技术及框架争论了很久，到底是用jsf还是别的web框架。我的观点是坚持不用jsf，而别的同事坚持用。他们就认为jsf开发速度快，有很多现成组件可以使用。我不否认jsf是有很多现成组件，可是有时候，我们做项目中，难免会遇到一些很特别的需求，大家都知道jsf开发组件太困难，对它的控制力不够强，而且不够灵活，这样我们在实现这样比较特别的需求就很难做到。而使用别的web框架却是很容易的事情，因为它足够灵活，对它的控制足够的强。

13 楼 fins 2008-04-10  

我觉得一个B/S系统中 应该有两个框架 一个负责s端 一个负责b端
他们可以是一个公司的一个产品的两个部分
甚至可以有一样的名字

例如 fins's server framework 和 fins's UI framework
但是 如果有一天 我觉得 fins's server framework 不好了 那么我可以换成

snif's server framework ,
oahnarret's server framework
UI不好了 我也同样可以换成其他类似的方案

我不需要一个 B/S框架 我需要的是一个好的S框架 和一个好的B框架

但是sun似乎不喜欢和别人共处 总是希望一统江湖.
所以JSF出来了.

他一边高喊我有MVC框架,一边高喊我有面向组件的UI模型.

OK,那么我能不能 用JSF的后台框架 + 另一个UI层框架?
不能

我能不能用 简单servlet + JSF UI?
不能

为什么不能? 因为在sun的眼里,只有BS系统 而不是B/S系统 .

这点 让我很不爽.

该b做的就b做, 该s做的就s做 不好吗???

该谁做的事 就让谁做 这有什么不对吗



我觉得一个B/S系统中 应该有两个框架 一个负责s端 一个负责b端
三个太多 ,一个太少, 两个刚刚好

12 楼 fins 2008-04-10  

我的核心观点其实是 

1 JSF UI不够解耦, JSF的UI不算是UI
2 JSF野心太大 , 但是能力有限, 导致UI层的实现和设计都不好

11 楼 maku 2008-04-10  

我概括一下：
fins的观点是“jsf现有的UI使用起来效率很高，但开发自己的UI组件非常困难”。
terranhao 的观点是“JSF的,开发效率一定比AJAX+DHTML的高.”
terranhao也举了JSF基于UI开发效率高的例子，但是但是，terranhao并没有证明JSF开发UI组件的效率如何如何高。

其实无论是.net（c#...）还是jsf,开发组件都是很复杂的，虽然我也没有过jsf,但从论坛里了解的看，jsf恐怕要比.net的还要复杂。

10 楼 fins 2008-04-10  

在硬件飞速发展的今天运行效率不可能成为阻碍技术发展的瓶颈

但是引起运行效率低下的原因却值得探讨

复杂的设计　必然导致性能低下

ＪＳＦ最大的错误　应该是定位问题
server client哪个都像搞 结果哪个搞的都不好
就像"我的伟大发明"

为什么他能走到今天? 也许是因为sun从jsp+jstl里吃到了甜头

servlet ---> jsp --> tag ---> jsf
一路走来 sun的心越走越大 但是路却越走越窄

9 楼 terranhao 2008-04-10  

我反驳不了你.
我都是用别人的组件,myfaces  richfaces
JSF开发组件确实很麻烦.但是,优秀的组件非常多
干嘛要重复发明轮子.
你对JSF的批评根本没到点子上
JSF最大的毛病是运行效率比JSP低了2,3倍,不过企业级的应用服务器应该都是比较牛B的,所以大致来说效率可以接受.
你去jboss看看他的rich-faces的demo吧,再想想你做个这种效果出来需要多久?

8 楼 fins 2008-04-10  

补充一下
我所说的

JSF开发UI组件很麻烦

是指 开发组件 而不是使用已经开发好的JSF UI组件
我说的是 开发 不是 使用

7 楼 fins 2008-04-10  

to terranhao:

你说了那么多 其实我觉得真正有意义的话只有一句

引用

当我用了jsf+richfaces之后,我才发现,原来效率可以如此之高

也就是说 你看到的是 jsf在 RAD方面体现的优势

你看看我的文章, 我什么时候否定jsf能够RAD了??

可以这么说: 如果有好的IDE ,足够好,那么很多技术都可以实现快速开发

但你不能说那些技术是好技术

我俩站的角度不同
我是在设计 和模式角度来分析 我觉得他的设计不够好

如果你要反驳我 能否针对我对jsf提出的质疑 逐条反驳???

1 JSF UI和JSF其他地方结合太紧密
2 JSF开发UI组件很麻烦
3 JSF没有足够出色的组件实现 (比开源免费的 纯ajax的 EXT更好的 )
4 JSF导致ui层和后台无法做到以数据为中心

另外 你是否认同我最后说的那段话:

引用

在B/S系统中
UI层与系统其他层面的东西的唯一联系应该是"数据"
UI层应该是在后台系统不变的情况下可切换的

总之两个字"解耦".

任何违背这个准则的框架我都不认为是好的框架. JSF WICKET DWR 都不是.
事实上,我不认为有哪个框架 可以同时做好 后台和前台两个层面的工作.
既然做不好 那就别做.

整齐划一是好的,但是 我们应该 必须 一定 永远都要承认"分工"的存在.

最后问个问题:

你见过哪个西餐厅会放一把万能的瑞士军刀在餐桌上吗?
如果没有 那好, 请你也不要指望在 B/S系统开发领域内 见到一个万能的"瑞士军刀"

6 楼 JavaInActoin 2008-04-10  

两种不同的架构，JSF用于在Server端搞定一切，ajax-java是B/S系统。“客户端－服务”的架构更优秀，更解藕，更符合以后的发展。但传统的编程方式不会消失，还有一部分人在使用，因此JSF还是有一定用途的。等到大家都在使用“客户端－服务”架构的时候，目前的JSF自然就一无是处了。

5 楼 terranhao 2008-04-10  

也就是一句话,AJAX+dhtml能做的,JSF不一定能做
JSF能做的,开发效率一定比AJAX+DHTML的快.
至于JSF不能做的,他又没规定你不能在页面里用ajax+dhtml
至于上篇你反驳我的可维护性和效率是和编程水平和技术相关的,
我完全不同意.java代码百分之百的可维护性,阅读性比javascript代码强得多.
这和高手不高手,编程水平是完全两码事.

4 楼 terranhao 2008-04-10  

我觉得评论任何东西都是需要实际运用才能有发言权
当初我也觉得jsf很麻烦,学习麻烦,还要配置,不如我自己老老实实写表现层.
但是当我用了jsf+richfaces之后,我才发现,原来效率可以如此之高.
老板让我写一个人力资源管理的一个人事档案模块.
按照平时的进度我用struts做怎么也得一周吧.
我拿JSF来做就两天,几乎都是ajax,但没有写一行javascript,界面还不错.
当然,如果你觉得javascript写起来很爽,很high,那当我没说过
别看了两天书,就随意评论一个产品.他再怎么烂,也是apache的顶级项目,jboss的顶级项目seam也是基于它的.大哥,用用再下结论好么

3 楼 fins 2008-04-10  

再多说两句:

我觉得 在web ui层主张使用 jsf的人里
有相当一部分是 "java专家,但是对客户端技术了解有限,甚至知之甚少"
因为了解有限 所以心生恐惧 进而排斥.

2 楼 fins 2008-04-10  

多说两句啊 说说你对jsf的看法

实际上我很希望有很多人来反驳我

我希望我可以被说服 我希望可以有人给我足够的动力去学习和研究jsf

1 楼 抛出异常的爱 2008-04-10  

ext
正在学习中
目的很简单
减少学习ajax的麻烦