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系统开发领域内 见到一个万能的"瑞士军刀",
至于那个"我的伟大发明"你更是可以完全忘掉它了.

评论

39 楼 bluecrystal 2008-04-12  

jsf和asp.net的服务端组件技术同出一辙，说白了，简单点就是事件驱动机制的延续，只是为了达成目的所采用的另一种手段而已。你用筷子吃饭，还是用刀叉吃饭，反正你的目的就是要填饱肚子，何必在乎用什么东西吃呢，用你习惯和擅长的就是了

38 楼 lishali12345 2008-04-12  

真的看了大家的讨论，感觉受益匪浅啊！
一定要努力，努力到能真正看到大家的讨论！
小辈我真的还需要很大很大的努力才能到这个层次啊！
一定要加油！

37 楼 fins 2008-04-12  

我决定好好研究研究JSF 然后再来和大家继续讨论

我下一步打算 封装一个GT-GRID的 jsf组件版

我研究的目的不纯, 是为了证明 它确实不好. 也许带着这样的动机去研究并不是好事 呵呵

36 楼 semicircle 2008-04-11  

原来B系统和S系统那篇文章是你写的。
hint：我是TY。

35 楼 fins 2008-04-11  

casazaft

其实我的想法挺简单的.

一个复杂的系统 现有的ui组件无法满足需求
我需要自己开发大量的ui组件.
这时候 如果是用jsf 那么开发调试过程很痛苦 就像我说的:jdk tomcat 之类的东西一个不能少.

而且开发人员java ajax都要掌握.

而一个充分解偶的b/s系统 完全可以更轻易的做这种分工和分层开发.

同时更容易实现 一个server为多种展现层技术服务 (html jsp php asp ....)
我完全可以开发出一个 php+j2ee的系统


关于你说的 数据协议(格式)的问题 我觉得不是大的问题
s和b之间传输xml也好 json也罢 归根结底是一种"字符串的游戏"
把pojo map resultset sdo....不管是什么 都是要序列化成一个字符串.
而这个 字符串的转换完全可以通过一个通用的 或者是很薄的层来实现.

关于js
js好多年没有大的发展是因为 人们认为js在那段时间已经足够用 没有足够的动力和理由去做大的改变. 而现在为什么要出2.0 3.0....
就是因为 人们渴望在b端做更多的事情. 同时 随着浏览器 客户端主机的飞速发展 b端也有能力来做更多的事情.
所以 该b端做的事情就让b端来做 这个思路 我觉得还是正确的.


关于java与ui
我这里讨论的是b/s 系统 也许java可以开发复杂的ui,也许web ui没有桌面系统ui复杂,但是java却偏偏不适合开发这种更简单的webui.

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


讨论这个问题是讨论不出结果的 就好像讨论 java vs .net 一样.

我并不是为了唱高调,也不是为了给自己不想学习jsf找任何借口
我只是想表达一下自己对jsf浅薄的看法 以及听一听不同的声音.

交流讨论的目的是为了充分表达自己的观点,而不是为了"战胜"对方.

对JSF反对的声音一直很多,但是我也注意到jsf这两年正在越来越受到重视.
但是我觉得它受重视的原因主要还是商业运作上的成功
sun提出的,标准的 规范的 统一的.... 在这些形容词修饰下的JSF 对那些银行 电信 电力之类的大型企业确实很有诱惑力.
而且借助ide 确实可以让众多水平参差不齐的软件蓝领 代码机器们高效的运转.

但是这种成功 我觉得不是真正的成功. 我还是坚持认为 以数据为中心的B/S模式 是更正确的.

34 楼 fins 2008-04-11  

引用

晕倒,我的环境差?! 那世界上可能就真找不到好的环境了!~
建议你好好打听一下,目前都是那些公司和组织在大面积使用JSF!哼哼!

晕
我说差很多 是指相差很多 是指差异的意思
你还真会联想

你那个 "哼哼"两个字用的真是太帅气了 你牛


我对jsf提出的质疑和我的问题 你不正面回答 却总是在说一些类似"你不要为了分层而分层之类"的 唉 无奈

33 楼 zqrain 2008-04-11  

就算是小概率 也正是因为系统进行重大的改变和升级需要太高的成本,所以很多企业设计一套系统要用近十年不升级. 

我猜想这应该不是什么产品把,应该就是你说的项目了吧!(其实,我本毫无贬低项目开发之意)

引用

我无意贬低你 也无意贬低你所从事的工作, 但是你所接触到的 你所身处的环境 真的真的和我在讨论这个问题时 所设想的环境 差的太多.

晕倒,我的环境差?! 那世界上可能就真找不到好的环境了!~
建议你好好打听一下,目前都是那些公司和组织在大面积使用JSF!哼哼!

本来还以为你是一个爱学习的青年,所以跟你聊聊,以免你错过一个好的技术,跟是害怕因为你的连续两个帖子误导一匹同样好学的人.

但是,你的无知和故步自封太让我失望了.(最讨厌一些菜鸟没搞清楚一个技术就胡乱批评)

送你一句robin说给hibernate反对者的话:你要用就用,要不用就不用!

32 楼 fins 2008-04-11  

casazaft:

首先非常感谢你 一直能够以一个平和的心态与我这个偏激的JSF小白痴讨论问题.
非常感谢. 

引用

java程序员有需求也有必要使用一套能跟java无缝配合的Web UI框架，官方推的就是JSF

我可不可以理解成 JSF压根就不是为有"我所说的那种松耦合"需求的b/s系统而生的?

它的出现就是为了让那些java程序员也有能力来编写复杂的UI组件??


如果是这样 那么 我说:
它不是一个好的架构设计 , 因为java不适合也不擅长做UI组件.
UI组件也不应该让java程序员来做

我的这个观点是否有错呢?

casazaft 写道

那么页面的逻辑就必然用很多JS 来实现，如此一来重用性大为降低

这个观点我是不同意的.js这种运行在页面里的灵活的脚本语言来做页面逻辑绝对要比java合适很多. js也可以组件复用啊. js也可以封装成组件啊.
认为他难,很大程度上是因为团队里缺少能够熟练驾驭它的人.
但是不能因为队伍里没有会飞机的人,就认为飞机没有汽车好啊



可能很多人认为我对java j2ee有敌视情绪. 其实恰恰相反. 我从大学开始接触java,也在东软那种使用j2ee开发大型项目的公司工作过很久. 所以我对j2ee有很深的感情.

我也知道对于那些做项目的公司来说, 能够低成本的按期完成项目最重要.
他们恨不得程序员按一个按钮 所有代码都自动生成,不管生成的代码多垃圾,只要能满足客户的需求 能交工就OK.

但是 我在这里探讨的不是 "什么技术能帮助企业赚钱" 而是 什么技术从长远来讲是更合理的,是更适合B/S架构的.


有位朋友说"不要为了设计而设计", 但是在说这句话的时候, 请先指出这种"设计"有什么不好, 不要因为你不认同这种设计就说这种设计是"为了设计而设计"( 这段太绕口了 呵呵)


请大家能和我一样,带着一颗浪漫理想主义的情怀, 揣着一刻追求更高目标的心情来看待问题.

如果讨论 java 和 .net到底哪个低层设计好时,

我说: java好,因为windows server不免费.
你说: websphere 也不免费啊 而且贵的要死.
他说: 但是可以用免费的j2ee容器啊
你又说: java看似免费,但是后期投入成本还是很大的

....

你觉得这是讨论技术的好方式吗?

不要总是拿"JSF可以帮助公司快速完成项目"来举例. 如果有好的IDE,有很多垃圾框架都可以做到快速开发.




我还是要再说一次:
开发一个用来在浏览器里展现数据的树形组件, 我居然要安装jdk 要安装tomcat 安装数据库.... 这是多么荒唐的一件事啊.

31 楼 fins 2008-04-11  

casazaft:

引用

页面的显示逻辑和应用程序逻辑可以完全分开

这个该怎么理解呢?

我觉得JSF 就是把 页面逻辑挪到了 server端来做.

可能在server端两种逻辑是分离的,
但是我点击一个链接跳转到另一个页面
或者是点击A按钮后隐藏b列表 这种纯的展现层的东西,为什么要用标签封装起来 交给后台来做呢???


不是反问 也不是质疑, 而是真的是疑问句, 是想知道原因.

30 楼 fins 2008-04-11  

zqrain :

不要为了模式而模式 不要为了解耦而解耦 不要为了设计而设计...
这类的话我听到太多了


但是我想听听 B和S 解耦 有什么弊端 ? 有什么坏处?


你认为这种需求是“小概率事件”?
就算是小概率 但是他也是必然要发生的事,因为企业的系统是要更新换代的. 也许更新的时候不会再找你们公司做,所以你可以不必去想 更新换代的时候有多痛苦.

就算是小概率 也正是因为系统进行重大的改变和升级需要太高的成本,所以他在有些时候才会成为小概率事件.

就算是小概率  也正是因为系统进行重大的改变和升级需要太高的成本,所以很多企业设计一套系统要用近十年不升级.

而解耦正是为了降低这种风险和成本.


你认为这种设计提高难度? 错了 这可以更好的分工. 更好的让专业人才在自己擅长的领域内发挥威力. 而不比让所有人都成为全才.

你也许没有开发过复杂的系统, 没有开发过需要你自己写组件 自己扩展框架的系统
你做的系统也许只要 使用JSF(或其他框架)现有的东西 在IDE的帮助下, 就可以完成

但是 请你再多想一想. 从开发的整个周期来想一想.

引用

开发一个用来在浏览器里展现数据的树形组件, 我居然要安装jdk 要安装tomcat  安装数据库.... 这是多么荒唐的一件事啊.

我无意贬低你 也无意贬低你所从事的工作, 但是你所接触到的 你所身处的环境 真的真的和我在讨论这个问题时 所设想的环境 差的太多.

我们不是一个领域内的.  存在即是合理的,所以 你可以说JSF是优良设计 你也可以说jsf很好, 但是你所说的内容 无法打动我.

29 楼 笨笨狗 2008-04-11  

其实对于精通js、css的人来说，更习惯于自己来，用封装好的jsf，用java生成js这种，就好象你看技术图书，不看原版而去看翻译版的，别扭。
所以，我连ext都不用，继续Prototype、Script.aculo.us，后面来个rails得了。

28 楼 zqrain 2008-04-11  

不排除有些产品在改版的时候使用新的技术架构，但是我还真没有见过其他层基本不动，仅仅修改一个层的。

为了这种“小概率事件”过分地在每个系统中引入这种没有必要的复杂性，是不是可以用“过度设计”这个词形容。

另外，JSF组件绝对不是不可扩展的。如果你确实发现Dojo不是你想要的，你完全可以重写你的render，把它改写成EXT实现，你的应用程序根本不需要做修改。难道这种架构不比你的“刀耕火种”更灵活，更具扩展性？！

27 楼 zqrain 2008-04-11  

（1） 关于分层，我的意见是：不要为了分层而分层！

（2） 关于B和S解耦的说法，谁说SOA的S只能在browser端调用，我在Server端调用service然后使用JSF组件展现，不是很好吗？！

（3）关于“解耦合”，请问解耦是为了什么，你的解耦合又是不是为了“解”而“解”？你做产品也好，做项目也好，请问有几次是前台用Dojo， 结果后来发现EXT更好，于是用EXT重写的？！（或者类似情况）

如果真的出现这种情况，呵呵，那可能就不简单可以解释为技术或架构问题了！！

26 楼 fins 2008-04-11  

to zqrain:

引用

请问一下的语气属于讨论还是批判？

那我重说:

引用

我没吸过毒 没杀过人, 但是我也可以批判 "那么做是不对的"

回归正题.

你的意思是不是说:
b/s系统没必要分层,或者说没必要做到我所说的那种分层.
只要能快速的解决问题, 管他是几层呢.
对吧?

另外关于JSF的客户端展现技术我知道可以用多种技术实现,这个我已经说过很多次了.
但是问题就是他的做法根本就不够好.

还是拿EXT举例子

jsf ui可以和ext结合,但是这种结合并不是 即插即用 更不是可替换的
因为ext并不是插到jsf上, 而是和jsf紧密的结合在一起,不可分离.
自己写各种java代码,然后java代码里out.print各种ext专有的js代码 html代码等等.

我承认,如果这个封装好了, 也就是说,你拿到一个封装好的这种jsf ui, 在IDE的帮助下使用起来还是很轻松愉快的.
但是 我质疑的是, 这种结合各种客户端的方式 是否合适??

还有 rest ws soa 这些东西的出现(虽然有些时候又炒作概念的嫌疑),为的是什么?
服务 资源 松耦合 才是这些东西背后的核心.

采用jsf的系统, 能不能做自如的切换s端 或b端的技术框架呢?

引用

也许你没有意识到 S和B松耦合的重要的意义.

可能你是站在做项目的角度: 能快速的完成项目就OK.
而jsf可能恰巧能满足你的这个需求,它可能会很好的解决了你在开发期遇到的一切问题,而这些也正是你所关心的---你仅仅关心的.


而我关心的是 jsf这种模式,在b/s领域内 是否是最好的解决方案, 我侧重的用jsf开发出来的东西的质量(我所说的不仅仅是指 能够运行 能够完成需求中的功能, 还包括适应变化的能力 适应未来的能力 以及架构是否出色 是否合理).


解耦, 是软件设计永远的核心.

在web X.0  entrpirse X.0 soa rest 这些东西被大肆鼓吹的今天,
你要是不能意识到前后分离,彻底解耦,面向服务..... 这些东西对B/S的意义,
那我们也许就真的没法沟通了.

25 楼 zqrain 2008-04-11  

不过必须指出，用JSF开发并非理论上讲的那么简单。掌握JSF从而发挥它的高效生产力并不那么容易，需要一定的知识储备和时间来熟悉，掌握。

就像MFC刚刚出来的时候，很容易被误用，甚至于到它的鼎盛时期，也不是很轻易就能找一个MFC的高手。甚至就像现在的Hibernate，找一个会用的人，容易；找一个精通的，有点难！

而且，JSF也刚好处于rich client浪潮中的变革期，很多JSF rich client组件库还并不是是非成熟和完美，还需要一段时间让它逐渐优化，从易用性，功能性，开发效率等多方面更进一步。

无论如何，JSF绝对是值得期待的一项技术！

24 楼 zqrain 2008-04-11  

引用

我没吸过毒 没杀过人, 但是我也可以拉杆子讨论 "那么做是不对的"
不过 有一点我自己也认同"不了解就没资格批判"

请问一下的语气属于讨论还是批判？

引用

关于jsf的ui层的实现有多么拙劣 我就不多说了,
如果有哪位能找出一个做的很好的 效果比ext qooxood dojo 之类的更好的东西请告诉我.

另外，需要澄清一点：对于JSF的rich client端效果，在实现技术上完全开放的。你所熟悉的很多Ajax框架，甚至包括Flash和Flex，都是可以作为JSF组件实现的备选方案的！而作为调用者，是不应该过多关心这些实现细节的。

JSF的优势在于“组件化”。

刀耕火种的时代已经过去了，如果你不是在培育什么特殊绿色食品，请学习一下机械化大生产吧！（这里的绿色食品是指有些不使用化肥，农药，纯手工种植，采摘的经济作物－－现实中的确有这种需求）

23 楼 zqrain 2008-04-11  

引用

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

引用

JSF UI (不管太最终用到的是ajax也好 flash也罢),
是不是破坏了这种分工 破坏了这种松耦合性?

请问，软件为什么要分层？！

大家都知道，通常意义上将，网络是分7层的，而在JAVA里面，我可以建立socket，然后取得流，最后仅仅调用

InputStream.read()

就直接把远程的数据获得了（不需要多层的处理）。这个是不是“破坏了这种松耦合性”？！

22 楼 fins 2008-04-11  

谁来告诉我一下 我下面的观点,有错吗? 错在哪呢?

引用

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

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

JSF UI (不管太最终用到的是ajax也好 flash也罢),
是不是破坏了这种分工 破坏了这种松耦合性?

21 楼 fins 2008-04-11  

我没吸过毒 没杀过人, 但是我也可以拉杆子讨论 "那么做是不对的"

不过 有一点我自己也认同"不了解就没资格批判"
我拉杆子讨论的目的就是希望有人可以说服我
让我对JSF重燃希望 让我可以心甘情愿的去学习JSF

20 楼 zqrain 2008-04-11  

引用

只是我不是JSF领域内的专家

晕倒，你对JSF又不是很熟，干嘛还拉杆子讨论JSF？！

(1) 实在必须澄清一个观点，JSF并不是主张在Server端搞定一切。给你们这种影响是因为JSF出现的初期，Ajax等rich client技术还不是很成熟。

如果你们深入研究一下JSF的最近产品，比如Oracle的ADF 11g或者JBoss的seam，相信你对JSF有新的看法。

(2) JSF思想在于“组件化”。就像当年MFC等桌面框架给程序员提供方便的应用系统组件一样。MFC的组建使你不再需要考虑过多的事件处理与操作系统调用相耦合； JSF的组建则是给你屏蔽了HTTP处理细节（这种封装性远非struts等框架可比）。

(3) 没有包治百病的药，JSF也一样。JSF面向的是以开发效率为首要权衡因素的Java BS框架，它适合大多数企业应用系统。如果你非要拿它做类似browser上的游戏这种高度非组件（或者说需要的组件都不通常系统的常用组件）的软件，那JSF确实是鞭长莫及。

另外，由于框架本省的限制，JSF在运行效率和内存消耗上可能会比手工写java＋javascript稍有逊色。但这不是攻击它的理由。如果你非要跟我将效率，我并不反对你拿汇编写你的程序，这个跟我无关！呵呵