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

评论

79 楼 hax 2008-04-19  

lcllcl987 写道

UI层应该是在后台系统不变的情况下可切换的

fins 的眼光太狭隘。
fins狭隘到只有在游览器上运行的东东才是b， 在容器中， 哪怕是web容器中运行的就是s了。
但是如果把眼光放高点，也就是更广义的来看， 对于一个J2EE应用来说
UI层，应该是在web容器中运行的web框架， 比如JSF， structs等。

fins兄的眼光仅仅局限于web框架， 并且在web框架内部还要再继续划分一个所谓的B层， S层， 产生这样的谬论就不奇怪了。

那么你的眼光何尝不是局限于j2ee框架呢。

ui层可切换，那么后台可不可以换？

还有，为什么一定要web“容器”？

我们知道jsf的用意就是要去掉b/s划分。问题是这个划分是先天而成的，并不是fins划分出来的。所以质疑也是很好理解的。

且fins并没有说要在web框架里分b和s，fins的意思我认为是指他理想的Web框架是基于b/s解耦的架构。

78 楼 hax 2008-04-19  

fangshun 写道

  虽然自定义组件不好做，但是我的第二个项目，已经复用了很多第一个项目写的验证组件，转换组件，并且还在基础上不断完善，在第二个项目上又加入了一些有效的，特定方式的显示组件，也可以应用在以后的项目中，逐渐形成了一套自有风格的开发实践，很不错，而且代码很容易重构，变得极度精炼！
  对于jsf的批评仍在进行中，但是懂得实践的人，已经逐渐尝到了基于jsf的组件化，标准化带来的开发优势，让不动手的人继续讨论它的优缺点吧。。。。。。。。。。。

组件化不是只有jsf才能做到的。至于标准化么，这个就见仁见智了。

77 楼 fins 2008-04-19  

引用

除了Myface,每一个Java开发人员都已经安装了以上其他内容,从做Java开发第一天开始,你觉的这个哪里不正常了?

安装正常
但是我开发页面却要我把后台的东西都启动 都运行 这个正常吗?

我机器里安装了很多软件 但是我做一件事时 一般只打开和这件事相关的软件 能少开就少开

开发前台页面也是一样 我一般只用一个文本编辑器 必要的时候也许会启动一个小型的httpserver.
随时编辑 随时调试 随时预览 无需编译 无需部署 这样不好吗?

不要质疑我不懂得j2ee eclipse jsf. 我接触这些也有很长时间了
(jsf不长 但是我一直觉得他就是 tag servlet  filter 的加强版)


其他的我也不回你了 回起来太累
如果有机会也许当面讨论 更合适 只是不知道到时候会不会因为意见不合动起手来 呵呵.


不管我俩观点怎样不同 但是有一点我很感动:
你是很认真的和我在讨论问题 否则你也不会写那么多字来回复我 谢谢你的认真.

76 楼 icewubin 2008-04-19  

我来帮fins解释一些东西吧，或者说我的观点吧，希望能有人看到：

引用

我使用JSF 1年多,从来没有借助过IDE来完成JSF页面组件的使用,自己写就行,组件的使用很方便.

你不借助IDE不是放弃了JSF的最大优势么？你使用方便不等于你的下属使用很方便。

引用

引用

我前面说过, 我做一个展现2维表的web页面 测试的时候 我需要安装jdk tomcat myface eclipse... 这个正常吗?

除了Myface,每一个Java开发人员都已经安装了以上其他内容,从做Java开发第一天开始,你觉的这个哪里不正常了?

这一看就是你没明白fins的意思，呵呵，其实很多时候要先做售前项目，或者是先做UI设计，就非常有用了。
有可能你们公司是做外包的，不担心需求的问题。
或者说，需求先行能解决很多需求理解行的问题，试想一下开发过程，系统解耦优秀的话，可以非常方便的让UI工程师先把界面做出来而不依赖任何服务端的代码，进行需求确认，或者说是敏捷思想的小步迈进，是非常重要的，这个时候发现需求理解有问题，返工的工作量要比后台都搭起来以后要小很多。

引用

这样做是挺好的,等你这头(B系统)调好了,准备和那一头(S系统)调试的时候,S系统不需要安装JDK,tomcat和服务端程序, controller, Json-libarary, something like that?

同上。

引用

是否意味着你发现Ext不能满足你的时候,你也自己Develop? 如果JSF 能提供80%以上的组件给你用,你觉的值吗? Reuse的价值很大,况且JSF绝对提供了良好的组件扩展方式.

自己参照EXT的框架和规范，或者其他方法Develop的成本不大的，因为选择余地很大。JSF 能提供80%以上的组件是你认为，我不认为。这个“能”是有歧异的。

引用

我其实想象不出来,你那些系统都要有什么功能? 我和很多人的说法一样,足够了.毕竟,我们开发大部分B/S系统都是普通的管理信息系统.

我进一步怀疑你们是做外包的。我认为即使大多数人甚至与我自己都不认为界面花哨有啥用，但是客户，客户验收人员，客户负责人的老板，我们自己公司的上层和老板就是喜欢，嘴上从来不承认，但是可以观察出来的。界面优秀的作用（实际的例子）有机会我单独发帖说明（我比较懒，还没单独发过帖，怕没人看啊，浪费啊）。

引用

JSF是作为Struts的替代品而来的(Struts的作者是JSF规范的主要制定者),来的晚,但技术及理念上要比Struts先进(即使是Struts2还是摆脱不了form驱动,UI没有组件化的问题),所以,JSF比例会逐渐提高. Spring MVC大部分情况只是被用做Controller.

Spring MVC没说要替代Struts，在我们公司的Appfuse中是因为MVC的弱化，和用了极精简配置，就不高兴再换了，因为在我们的方案里Controler里面代码非常少。
我认为JSF出现的太晚了，如果他能和Tapestry差不多同时出现，就不会像现在这样推广缓慢了。你也不要认为客户端的框架就不算组件化了。

引用

至于Ext,Dojo这一类基于Javascript的架构,会有一部分系统,比如那些有很高用户体验要求,操作复杂灵活的,但功能相对较少系统会采用. 但在大型的管理信息系统中采用的比例不会太高,这样的系统最终还是会选择开发效率高,易于维护,基于标准的技术,比如JSF, Struts.

SAP算大型管理信息系统么？他们马上就要上Flex了，开发效率高么？易于维护么？标准都是慢慢形成的，想想3年前的Hibernate吧。

引用

历史原因,公司里有三个产品,其中一个是JSF做的,其他两个是"历史沉淀"的杂牌军.
后来公司里需要做一个整合,把三个系统集中到一个portal服务器,由portal提供更好的用户体验.
jsf可以不用做任何改动,只要在portal容器中配置对应的portlet就OK了.那些历史沉淀就傻了.没有任何褒贬的意思,只是一次经历.感觉标准还是非常好的东西.

你们公司走跟着这些大厂商走，这是当然的啦，咋不说你用微软的更方便呢。
个人愚见，portlet本身也是历史产物，现在眼光看也是个大忽悠，和EJB一样。

引用

还有关于权限验证的经历,一直觉得JAAS巨麻烦.快速应用开发,还不如自己写ifelse来的快.是的,ifelse贪图一时快乐,很有效果.就像楼主所说的,拿个文本写个html就马上能看到效果.但是产品继续做,继续维护和升级,继续和更多的外部产品整合,那些快捷的方案都会疯狂了.

有很多现成的框架可用，不用自己开发的。

引用

EXTJS是个很好的东西,他的API也很优雅,但是他绝对不是展示层的解决方案,注意我所说的是解决方案.用它写桌面浏览器的的portal也很酷,也可以用它在jsf输出的添加一些更好的用户体验(但是我更愿意采用DOJO),或是写几百行的javascript,给浏览器中的html添加一些很酷的效果.但是这些都只能是pc浏览器,而在手持设备上,就不能采用这种方案了,而jsf则可以继续用.

都讨论到手持设备上，厉害。你告诉我哪家方案手持设备用的时候JSF的方案并成功实施的。

引用

假如本身带着挑刺的观点去看一个东西,会发现,它是越来越讨厌,而忽略了他的迷人之处.

没说JSF不迷人，出来的太晚，推广的太慢，当年优秀的架构现在已不再优秀。以目前的眼光来看就是不再优秀了。

75 楼 lucumu 2008-04-19  

to fins
>J2EE jsf 要解决的问题我想我还是明白一些的
>快速开发 机械化生产 符合标准 统一 规范....

历史原因,公司里有三个产品,其中一个是JSF做的,其他两个是"历史沉淀"的杂牌军.
后来公司里需要做一个整合,把三个系统集中到一个portal服务器,由portal提供更好的用户体验.
jsf可以不用做任何改动,只要在portal容器中配置对应的portlet就OK了.那些历史沉淀就傻了.没有任何褒贬的意思,只是一次经历.感觉标准还是非常好的东西.

还有关于权限验证的经历,一直觉得JAAS巨麻烦.快速应用开发,还不如自己写ifelse来的快.是的,ifelse贪图一时快乐,很有效果.就像楼主所说的,拿个文本写个html就马上能看到效果.但是产品继续做,继续维护和升级,继续和更多的外部产品整合,那些快捷的方案都会疯狂了.

EXTJS是个很好的东西,他的API也很优雅,但是他绝对不是展示层的解决方案,注意我所说的是解决方案.用它写桌面浏览器的的portal也很酷,也可以用它在jsf输出的添加一些更好的用户体验(但是我更愿意采用DOJO),或是写几百行的javascript,给浏览器中的html添加一些很酷的效果.但是这些都只能是pc浏览器,而在手持设备上,就不能采用这种方案了,而jsf则可以继续用.

假如本身带着挑刺的观点去看一个东西,会发现,它是越来越讨厌,而忽略了他的迷人之处.

很少参与JE的讨论,感谢fins发起这个话题,让我们对"事物"本身有了更多的思考和了解.

74 楼 fxy1949 2008-04-19  

回你的贴还真有点麻烦,发现你真的挺能说的,所以这是最后一贴.

我写这篇文章 只是表达一下自己的想法
没有任何目的 也没指望这篇文章弄够影响到别人
也从来没有试图改变别人的想法

"忽悠"从何谈起呢?

写文章我觉的不是自娱自乐,比如说,我回你的贴就是不想让你那些偏颇的观点误导别人. 你说没指望能够影响到别人,也从来没有试图改变别人的想法,真的是这样吗?

说你忽悠,是因为你总是拿什么”解耦”,”B系统”,”S系统”,什么”伟大发明”,用在B/S系统开发的场景,关键时候就来一通. 这不是什么发明创造,这就是在忽悠,最好使用正常的技术语言讨论技术问题.

关于这个问题我没法说道你所谓的点子上 因为我说的"点子"你看不到
而我之前针对JSF的那些质疑 也没有人能解答
(我怀疑你没有认真的看完每篇回复 看完主贴就来炮轰我来了)

看了你对JSF的质疑问,还真的不知道怎么解答.因为你的问题我几乎都不太能确定你的意思.
你在对JSF非常不了解的情况下,问出下面问题有意义吗?不过,勉为其难,我还是想尽力答一下.

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

1) JSF本来就是要实现Http Request统一的,规范的,以事件驱动方式的处理,Web Server和Browser之间传送http request(上传)和html(下传),不亲密点行吗?
2) 实际情况是,作为普通开发人员,根本不用自己去开发,拿来使用或扩展即可. 你使用Ext不也是只是使用吗? 你也不需要去开发,道理是一样的.
3) 最重要的一点(这个要你好好学了JSF才能理解)是: 标准JSF UI组件达不到类似Ext的效果,灵活性(比如说频繁和服务端交互)的原因是: JSF UI组件的数据(MVC中的Model)都在Web Server Session中,要改变或获取只能靠Http request/response的方式; 而Ext之类组件的数据全部都先取到Browser中,或动态通过Ajax获得. 如果你说这个是JSF的不足,也对,但这也是JSF的核心观念之一,Web Server保存其数据(Component Tree),Browser负责Render Html(数据来自component tree ). 当然,现在有了RichFace之类的技术已经能弥补这个不足.
4) 无法以数据为中心? 又来这个,为啥就不好? 给个理由先. 千万不要说切换前台或后台会比较方面.

J2EE jsf 要解决的问题我想我还是明白一些的
快速开发 机械化生产 符合标准 统一 规范....

但是JSF要达到这个目的不一定非要像现在这么设计吧?
换个角度 B/S解偶 之间尽可能的只用数据做桥梁 这种设计难道就达不到
快速开发 机械化生产 符合标准 统一 规范....吗?

上面这段又开始扯了,认真学习JSF两个星期,你就知道你讲这些简直是蜚夷所思.

如果JSF能够快速的开发出后台业务逻辑
同时能够快速的开发出前台展现.
前后可以更好的解偶,为开发和测试提供更大的便利
同时提供一定的灵活性(可扩展 可替换) 这样不好吗?
难道这样就影响快速开发了?

看到这里,我已经快不能承受了. JSF和开发后台业务逻辑能搭的上吗? 连最基本的JSF原理都没有搞明白,在这里说JSF为什么不能做的更好?不觉的好笑吗?

我总结一下jsf的优点:
借助出色的IDE,可以帮助"代码机器"们快速的构建起一个可用的项目.
而且这个项目并不复杂,无需开发人员扩展jsf的组件.

我使用JSF 1年多,从来没有借助过IDE来完成JSF页面组件的使用,自己写就行,组件的使用很方便.

除了这些还有什么呢?

实不相瞒,真的还有挺多.

我前面说过, 我做一个展现2维表的web页面 测试的时候 我需要安装jdk tomcat myface eclipse... 这个正常吗?

除了Myface,每一个Java开发人员都已经安装了以上其他内容,从做Java开发第一天开始,你觉的这个哪里不正常了?

我希望的是 我可以在简单的文本编辑器里编写代码,在浏览器里测试运行, 测试时的数据我可以使用xml或json轻松传给列表组件
这样的做法不好吗?

这样做是挺好的,等你这头(B系统)调好了,准备和那一头(S系统)调试的时候,S系统不需要安装JDK,tomcat和服务端程序, controller, Json-libarary, something like that?

我都怀疑你都没有用Eclipse,such a great IDE. 也有专门针对JSF的测试工具,单元测试,集成测试应有尽有. 在文本编辑器里敲代码,你觉的Cool,我一点也不觉的,过时了.

也许有人会说 jsf有很多组件 列表组件现成的 不用你开发 不用你测试 不用...
对不起 请打住, 你是jsf的user 我是developer.

是否意味着你发现Ext不能满足你的时候,你也自己Develop? 如果JSF 能提供80%以上的组件给你用,你觉的值吗? Reuse的价值很大,况且JSF绝对提供了良好的组件扩展方式.

而且jsf那些组件我看过很多, 我很差异 为什么很多人都说那些组件足够用了呢?
我很奇怪 那些说组件够用的人做的是什么项目.
是不是只是一些对数据库记录的 查询和 简单编辑?

我其实想象不出来,你那些系统都要有什么功能? 我和很多人的说法一样,足够了.毕竟,我们开发大部分B/S系统都是普通的管理信息系统.

我以前和现在所在的公司都对jsf进行过考察,说实话 没有一个组件包是够用的
想满足我们验证项目的需求
我们用来验证JSF的项目是:
某电信BSS系统 ,
某公司人事管理系统,
某应用管理系统(类似websphere的web控制台)

想实现我们的需求,要从各个组件包里提取各种组件进行组合 而且还要自己扩展很多

我真的很好奇 那些说现在的jsf组件已经够用的人 做的是什么项目

你讲这些一点都没有说服力. 我就问一个简单的问题: 目前Java世界里, Web层开发技术到底是怎么分布的?
1) JSP
2) Struts, JSF, Spring MVC
3) Ext,Dojo,YUI ……
4) JavaFx,Flex... (可能未来不久会流行)

以下是我的判断和体会:

目前,JSP还有一部分, Struts绝对是主流,因为比较成熟和被广泛使用,你去看到处招人都是精通SSH就知道了.

JSF是作为Struts的替代品而来的(Struts的作者是JSF规范的主要制定者),来的晚,但技术及理念上要比Struts先进(即使是Struts2还是摆脱不了form驱动,UI没有组件化的问题),所以,JSF比例会逐渐提高. Spring MVC大部分情况只是被用做Controller.

至于Ext,Dojo这一类基于Javascript的架构,会有一部分系统,比如那些有很高用户体验要求,操作复杂灵活的,但功能相对较少系统会采用. 但在大型的管理信息系统中采用的比例不会太高,这样的系统最终还是会选择开发效率高,易于维护,基于标准的技术,比如JSF, Struts.

73 楼 fins 2008-04-19  

J2EE jsf 要解决的问题我想我还是明白一些的
快速开发 机械化生产 符合标准 统一 规范....

但是JSF要达到这个目的不一定非要像现在这么设计吧?
换个角度 B/S解偶 之间尽可能的只用数据做桥梁 这种设计难道就达不到
快速开发 机械化生产 符合标准 统一 规范....吗?

如果JSF能够快速的开发出后台业务逻辑
同时能够快速的开发出前台展现.
前后可以更好的解偶,为开发和测试提供更大的便利
同时提供一定的灵活性(可扩展 可替换) 这样不好吗?
难道这样就影响快速开发了?

我总结一下jsf的优点:
借助出色的IDE,可以帮助"代码机器"们快速的构建起一个可用的项目.
而且这个项目并不复杂,无需开发人员扩展jsf的组件.

除了这些还有什么呢?

我前面说过, 我做一个展现2维表的web页面 测试的时候 我需要安装jdk tomcat myface eclipse... 这个正常吗?

我希望的是 我可以在简单的文本编辑器里编写代码,在浏览器里测试运行, 测试时的数据我可以使用xml或json轻松传给列表组件
这样的做法不好吗?

也许有人会说 jsf有很多组件 列表组件现成的 不用你开发 不用你测试 不用...
对不起 请打住, 你是jsf的user 我是developer.

而且jsf那些组件我看过很多, 我很差异 为什么很多人都说那些组件足够用了呢?
我很奇怪 那些说组件够用的人做的是什么项目.
是不是只是一些对数据库记录的 查询和 简单编辑?

我以前和现在所在的公司都对jsf进行过考察,说实话 没有一个组件包是够用的
想满足我们验证项目的需求
我们用来验证JSF的项目是:
某电信BSS系统 ,
某公司人事管理系统,
某应用管理系统(类似websphere的web控制台)

想实现我们的需求,要从各个组件包里提取各种组件进行组合 而且还要自己扩展很多

我真的很好奇 那些说现在的jsf组件已经够用的人 做的是什么项目

72 楼 lucumu 2008-04-18  

fins:
几年前我觉得自己会用tomcat开发OA,觉得自己会J2EE,后来直到有人当我面说"Tomcat just a toy",直到现在已经开始渐渐改变我的观点.到现在我是最后一帖, l987,1949,不管是不是马甲,觉得还是赞成他们说的多一点点.
搞java快8年了,还是不明白J2EE是啥玩意,不是指那些技术名词和技术实现,而是它为啥要那样子,出J2EE标准为了解决什么问题.我觉得这样能帮助你理解JSF为什么要那么做.

71 楼 fins 2008-04-18  

lcllcl987

不明白 为什么反驳我文章观点的人总是习惯 通过贬低我的方式
而不是 对于我对JSF的那几点质疑给出回应

唉 我到底狭隘与否 不是你说的算的

70 楼 fins 2008-04-18  

引用

没把你当白痴，只是觉的你挺能忽攸的，喜欢比喻但又牵强，喜欢强辩但又说不到点子上。

我写这篇文章 只是表达一下自己的想法
没有任何目的 也没指望这篇文章弄够影响到别人
也从来没有试图改变别人的想法

"忽悠"从何谈起呢?

关于这个问题我没法说道你所谓的点子上 因为我说的"点子"你看不到

而我之前针对JSF的那些质疑 也没有人能解答
(我怀疑你没有认真的看完每篇回复 看完主贴就来炮轰我来了)

xyz20003 说的很对

引用

价值观不一样，这个论不好辩啊。

69 楼 lcllcl987 2008-04-18  

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

一个B/S系统中 应该有两个框架 一个负责s端 一个负责b端
三个太多 ,一个太少, 两个刚刚好
---------------------
-----------------------
fins 的眼光太狭隘。
关于b/s,究竟如何划分哪个是b， 哪个是s？
fins狭隘到只有在游览器上运行的东东才是b， 在容器中， 哪怕是web容器中运行的就是s了。
当然，我不反对你这种狭隘的划分。
但是如果把眼光放高点，也就是更广义的来看， 对于一个J2EE应用来说
UI层，应该是在web容器中运行的web框架， 比如JSF， structs等。
对于JSF，backbean是页面标签的对等体， 自然是UI层的一部分（当然， 把business logic写在backbean中进而把backbean当作s，就另当别论了）。

至于s， 自然是提供服务的部分， 对于标准J2EE应用， 应该是EJB/Web service担任的角色。

fins兄的眼光仅仅局限于web框架， 并且在web框架内部还要再继续划分一个所谓的B层， S层， 产生这样的谬论就不奇怪了。

68 楼 fxy1949 2008-04-18  

fins 写道

To:fxy1949

看来做人不能太谦虚

谦虚一下不要紧 被你当白痴了

你压根没明白我在说什么

没把你当白痴，只是觉的你挺能忽攸的，喜欢比喻但又牵强，喜欢强辩但又说不到点子上。

67 楼 may_cauc 2008-04-18  

别争了，用flex吧，既符合b,s系统，你也可以把它用成b/s系统，^_^

66 楼 xyz20003 2008-04-18  

他肯定又说ajax4jsf呗。

现在正反两方同学的标准都不一样：
挺jsf一方同学说的是，有ajax能用，就非常非常ok了。
反jsf一方同学却在想，我要ext那种绚丽的富客户端，而且要响应及时，设计优美。

一边求快，求方便。一边要完美的设计。
价值观不一样，这个论不好辩啊。

65 楼 fins 2008-04-18  

引用

JSF与AJAX集成很容易

你是怎么集成的?

64 楼 hity 2008-04-18  

JSF STRUTS都用过，不过JSF事件驱动模式的确很先进。可以把动作细化到组件，而不是表单。后台backingbean只是简单的javabean不用实现任何任何接口和继承。配合Spring的IOC管理Hibernate和JSF 是不错的组合。JSF默认有个轻量级的IOC容器。但是大型项目一般都用spring管理。事实上JSF开发和维护起来都很方便。至于UI大型的企业级解决方案其实不看重这个。
可维护性-可读性-简单性 是大公司的首选。事实上UI与后台backingbean绑定只是用了个xml文件。耦合度也不是很高。改下xml就可以了。组件在后台都是可控制的。包括样式单什么的。看楼主似乎很专注于前台开发。但是一个程序主要的部分应该在后台吧我想？
我想说的是JSF的一些思想的确很先进。而且开发代码，可维护性 ，可读性很高。JSF与AJAX集成很容易。
JSF核心用到了大量的设计模式：比如说工厂模型  单例  等等。至少现阶段看，我认为JSF比struts1.x一些老的框架先进的。搞软件的应该记住一点：简单就是美。简单代表易于维护 简单代表降低成本

我是这么想的

63 楼 fins 2008-04-18  

引用

单单从灵活性上是很难说服那些使用JSF的支持者的

这话说的很对
所以我也没打算说服谁
表达一下自己就好了


认为我对的 可以走 数据为中心的 B和S解耦的路线.
认为我错的 可以继续走一体化框架的路线.

如果有一天 java不行了 , 我至少还有一个健壮的\独立的UI可以用,只要给我送数据只要给我提供各种服务,那么这个UI就会活着

如果有一天 ajax不行了 , 至少我还有一个提供各种服务的后台可以用.只要有一个可以调用后台服务的UI,只要这个UI可以展现后台推送的数据,那么我后台的代码还会活着

如果两个都不行了... 在这之前 JSF肯定早就不行了.


to 质疑我不懂jsf的人:

我确实不懂jsf,  就好像你不懂得我所说的话一样.

62 楼 magicstar 2008-04-18  

分析入理，评论一针见血，虽然我对jsF了解得不够，但目前确实感觉很多的框架存在这样那样的问题影响使用。

61 楼 qjzhyf 2008-04-18  

开发要讲究低成本，快速，而且开发人员也能在短时间跟进，力求做到项目进度合理，这一点是没有错，想念很多企业技术造型时，都会考虑到。如果到后期，进入维护阶段，用户提出新的需求，或者说需求变更频繁的时候，添加新代码能够快速，低成本，扩展性好，JSF有这样的好处，或者有这么一点的好处的话，这样是我所需要的。考虑如何分层，我觉得首先得先在开发与维护之间，找到一个扩展点，是不是更好呢？

60 楼 icewubin 2008-04-18  

fins 写道

fangshun :

你理解错了

我不是要把 jsf 和 某种页面技术混合评价

我哪句话让你有这种错觉了呢?

我知道 jsf在ui层是一个很有包容性的东西 ext之类的页面层技术完全可以理解为是jsf的一个子集, jsf本身是一个一体化的 一站式的解决方案 不仅仅关注前台技术.....

而我质疑的就是jsf这种做法  同时 我的观点很明确, 你可以前台后台都处理都涉及,
但是不能像现在这样 拙劣的将两者糅合在一起 使其无法分离.

再举个例子吧

大家见过那样的显示器吧:　显示器左右两边或者是上下是和音箱整合的．

我不反对显示器生产厂商提供这样一体化的产品　而且我也承认这在一定程度上简化了用户的购买电脑外设的流程　为搬运　使用提供了一定的便捷．

但是我不能容忍那音箱是无法拆卸的．　
音箱坏了不好修　我觉得音箱不好　或者是显示器不好时　无法单独更换．

总之　问题多多

不知道大家明白我的意思没

明白你的意思，厂家这么做更多的市场导向而不是功能和灵活性导向。估计德国人就不会生产这种垃圾。不过也没见过电视机的音箱能很方面更换的，都是要拆开电视机维修的。

存在即合理，很多OEM厂商就喜欢这种低成本集成设备。楼主举这个例子不是很合适，不过你要说明灵活性是可以的，但是凡是太强调灵活性也会失去讨论的意义，就像现在在讨论windows有多烂，并不能转变大多数人使用windows的现状，实际意义不是很大。我的意思是单单从灵活性上是很难说服那些使用JSF的支持者的。