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

评论

139 楼 fxy1949 2008-04-27  

<p>

hax 写道

建议icewubin将观点整理成贴发表，绝对是精华贴。</p>
<p> </p>
<p>最近忙啊，能有时间出来口水战已经很好了，我估计fins比我还忙，所以就替他口水战啦，客户端技术上我是远不如fins的。我也几次说到，有机会我会把我的观点整理出来，但是更过的是来源于生产实践，所以技术上没有太多的新意，更多的是从很多非技术的因素看待问题。
我也自认为就单项来说我是肯定不如很多人的，自我感觉整体把握还是不错的，也基本看透了更多的商业上的猫腻。
我自己在公司也准备把技术内容成文，我的北京的同事上次和我聊了半小时就强烈要求我写博客，我觉得要说的内容太多，还很难有条理性，不能精炼也是我的弱点吧，想到那说到哪。
还是想先把自己的想法归类以后分部分发贴或博客，一篇长篇大论大家看了也累。
（恩以上这段作为将来的开场白不错）

</p>
<p> </p>
<p> </p>
<p>Hehe,先别忙着捧脚和自我感觉良好,以后如果发现捧到臭脚,会后悔的;还有以后发现自己挺无知的,也会不好意思的.
对于Java EE 你们知道得还真的挺少,我建议不要轻言: JSF不行,EJB失败,什么大公司猫腻. Java如果没有Sun,IBM,BEA,等等大公司的支持,就不会发展到今天的地步.</p>

138 楼 csf178 2008-04-27  

说到底 这地方没一个真正懂JSF的（包括我） 稍微看看吧 哪种观点无所谓 别弄出一堆不懂装懂的言论来

137 楼 csf178 2008-04-27  

唯大公司论唯牛人论么？

是你们太自我膨胀 不知道自己是谁了吧 JSF有问题 但是不是你们这个档次的人看到的那点东西 别以为板着脸说的就一定不是笑话 就你们这些言论 要是让java社区看了 还不笑死

看看你们的发言中有多少在真正谈JSF的问题 谈技术要向 除了楼主fins说了两点 第12页xiao0556说的 哪有在谈JSF的 完全是在自吹吧 我就顺道提了下MS 调节下气氛 马上就拐到考我.net从1.1-2.0-3.0-3.5的变化有何看法了 这还像讨论技术？

JSF被人诟病是当然会有了 不过批评要有理有据 别张口就大公司如何如何 商业利益如何如何 程序员不谈商业 不管它出现为何目的 缺陷就是缺陷 优势就是优势 事实只有一个 它哪里强 哪里差都可以讨论 立足于技术上任何人都可以向sun的架构师挑战 只要你说的合理。

提提sun公司的架构师比我们强 不是因为我迷信他们 只是提醒下你们 至少在否定之前 先想想它哪里合理

到现在我没说我对JSF什么看法（估计我是没机会说了） 我也是做js的 从个人角度 我自然不会喜欢JSF 不过把JSF贬成这样 我还真说不出口

还有 EJB1.x在javaeye原来被定了死罪 火星了啊 这真是个令人振奋的消息

136 楼 icewubin 2008-04-27  

hax 写道

建议icewubin将观点整理成贴发表，绝对是精华贴。

最近忙啊，能有时间出来口水战已经很好了，我估计fins比我还忙，所以就替他口水战啦，客户端技术上我是远不如fins的。我也几次说到，有机会我会把我的观点整理出来，但是更过的是来源于生产实践，所以技术上没有太多的新意，更多的是从很多非技术的因素看待问题。
我也自认为就单项来说我是肯定不如很多人的，自我感觉整体把握还是不错的，也基本看透了更多的商业上的猫腻。
我自己在公司也准备把技术内容成文，我的北京的同事上次和我聊了半小时就强烈要求我写博客，我觉得要说的内容太多，还很难有条理性，不能精炼也是我的弱点吧，想到那说到哪。
还是想先把自己的想法归类以后分部分发贴或博客，一篇长篇大论大家看了也累。

（恩以上这段作为将来的开场白不错）

135 楼 hax 2008-04-27  

建议icewubin将观点整理成贴发表，绝对是精华贴。

134 楼 hax 2008-04-27  

csf178 写道

EJB1.x真的很失败的......

不会吧 有这回事- -!

原来您火星来的 -_-

133 楼 hax 2008-04-27  

csf178 写道

真是不愿意参与这种讨论呢

连sun的JSF架构本身的缺陷都给你看出来了 还很了解JSF的历史 我还能说什么呢 只能说sun这公司傻 这么简单的道理都不懂

微软内部技术派系斗争我可不了解 非技术问题别找我

JSF被人诟病不是第一天。你的唯大公司论唯牛人论可以休矣。5年之前做XUL的牛人就说Sun推JSF之类的东西无非是想多卖它的硬件（因为JSF等需要多得多的服务器计算能力）。按照他的观点，Sun不是傻，而是聪明过头了。

132 楼 csf178 2008-04-27  

EJB1.x真的很失败的......

不会吧 有这回事- -!

131 楼 leebai 2008-04-27  

csf178 写道

...
你不会认为JSF的架构师远远不如没事泡在这论坛的几个程序员吧？
就算差也差不了那么多对吧？

EJB1.x的架构师水平也是不差的。
可以EJB1.x真的很失败的，呵呵。

方向性的东西，尤其大厂商主导的，其主要出发点绝对不可能是技术优劣，而是商业利益，醒醒吧。

130 楼 csf178 2008-04-26  

我只会3.0 3.5所以没法对变化有啥看法
我只是个普通程序员 所以不敢替MS的架构师展望4.0
有啥展望就自己没事利用空余时间在3.5下写写了呗

另外啊 怎么跑题了 继续说sun啊 别说微软

129 楼 icewubin 2008-04-26  

csf178 写道

真是不愿意参与这种讨论呢

连sun的JSF架构本身的缺陷都给你看出来了 还很了解JSF的历史 我还能说什么呢 只能说sun这公司傻 这么简单的道理都不懂

微软内部技术派系斗争我可不了解 非技术问题别找我

或者说你对微软的.net从1.1-2.0-3.0-3.5的变化有何看法？以及将来4.0的展望？

128 楼 csf178 2008-04-26  

真是不愿意参与这种讨论呢

连sun的JSF架构本身的缺陷都给你看出来了 还很了解JSF的历史 我还能说什么呢 只能说sun这公司傻 这么简单的道理都不懂

微软内部技术派系斗争我可不了解 非技术问题别找我

127 楼 icewubin 2008-04-26  

csf178 写道

icewubin 写道

csf178 写道

解耦一直是架构中一个实践比较困难的设计原则
楼主一直在讲分层架构的解耦方式 显然也很认同
但是数据、逻辑跟表现之间还有纵向耦合 控件本身有一定独立性
至于究竟应该如何设计才能更好地解耦 就很难说了

所以至少JSF不是像你们说的那样一无是处
你不会认为JSF的架构师远远不如没事泡在这论坛的几个程序员吧？
就算差也差不了那么多对吧？

第一段你说得很好，我也没说JSF一无是处，我在讨论问题的时候更多的时候是从全局去把握，相对的考虑更多的非技术因素，因为非技术因素很多时候也很重要，比如我一直认为JSF有IDE的支持是一大优势，一直没有反驳过。所以没有说JSF一无是处，但是有些人没有仔细看别人写的东西而妄加评论就是非常不负责任了。

架构师应该同时应该掌握整个开发过程的效率，我也一直在说讨论是有前提的，当一个公司规模比较大，或者是开发技术已经由技术总监定下来了，或者是该公司得到SUN或者JBOSS的鼎力技术支持的，在这个情况下的架构师不管是主观的还是客观的都会利用公司的资源，用JSF组件做出各种优秀的设计。

一个公司对JSF技术投入有一年多，而且积累不少，对他们来说继续走这条路当然要比另起炉灶的成本要低得多。

当然你可以完全不理会这里的讨论，自己充分利用任何框架进行设计，但是不能在不了解其他框架实践的情况下随意的猜测别人的架构和应用方式，然后进行批判，这种猜测和批判是毫无意义的，而且多半都是和实际出入很大的。

- -！
没事 你们尽管说sun的不是吧 我不拦你们 我是支持MS的

可怜sun JSF的生存已经沦落到靠IDE讨好低端用户 或者给人家鼎力技术支持逼人家用JSF了
要不就得骗人家用1年JSF 弄的骑虎难下了 只好继续JSF了

虽然知道这不可能变成现实 还是暗爽 哈哈

不过 多说说JSF具体的缺点吧 像楼主说的 别沦为口才的较量

BTW "JSF的架构师"这个我没有说清 我是指sun公司设计JSF的架构师

据我所知，JSF的设计师的确很牛，但是不是重新设计的，是一个空降兵，好像是2003年到了SUN，接手了当时JSF的烂摊子，然后重新改进后推出来的，在03-04年的时候，整个架构体系当然是不错的，但是推广的太慢了，得到的支持力度还是不够，架构本身还有点缺陷，造成了今天有点尴尬的局面。很多时候技术的历史包袱是沉重的，就像EJB。

SUN本身还是有不少好东西的，如NetBeans、GrassFish等。

您是MS的fans，我一定要控制住自己，不和你讨论微软的好坏，呵呵，和我辩论的人可能都想不到我是Java的超级Fans呢。

说道微软，我有个问题向您请教，为什么微软的.net从1.1-2.0-3.0-3.5，为什么每次版本升级变化这么大？据我微软的同学说，好像是微软内部技术派系斗争的结果。是不是如此呢？

126 楼 csf178 2008-04-26  

icewubin 写道

csf178 写道

解耦一直是架构中一个实践比较困难的设计原则
楼主一直在讲分层架构的解耦方式 显然也很认同
但是数据、逻辑跟表现之间还有纵向耦合 控件本身有一定独立性
至于究竟应该如何设计才能更好地解耦 就很难说了

所以至少JSF不是像你们说的那样一无是处
你不会认为JSF的架构师远远不如没事泡在这论坛的几个程序员吧？
就算差也差不了那么多对吧？

第一段你说得很好，我也没说JSF一无是处，我在讨论问题的时候更多的时候是从全局去把握，相对的考虑更多的非技术因素，因为非技术因素很多时候也很重要，比如我一直认为JSF有IDE的支持是一大优势，一直没有反驳过。所以没有说JSF一无是处，但是有些人没有仔细看别人写的东西而妄加评论就是非常不负责任了。

架构师应该同时应该掌握整个开发过程的效率，我也一直在说讨论是有前提的，当一个公司规模比较大，或者是开发技术已经由技术总监定下来了，或者是该公司得到SUN或者JBOSS的鼎力技术支持的，在这个情况下的架构师不管是主观的还是客观的都会利用公司的资源，用JSF组件做出各种优秀的设计。

一个公司对JSF技术投入有一年多，而且积累不少，对他们来说继续走这条路当然要比另起炉灶的成本要低得多。

当然你可以完全不理会这里的讨论，自己充分利用任何框架进行设计，但是不能在不了解其他框架实践的情况下随意的猜测别人的架构和应用方式，然后进行批判，这种猜测和批判是毫无意义的，而且多半都是和实际出入很大的。

- -！
没事 你们尽管说sun的不是吧 我不拦你们 我是支持MS的

可怜sun JSF的生存已经沦落到靠IDE讨好低端用户 或者给人家鼎力技术支持逼人家用JSF了
要不就得骗人家用1年JSF 弄的骑虎难下了 只好继续JSF了

虽然知道这不可能变成现实 还是暗爽 哈哈

不过 多说说JSF具体的缺点吧 像楼主说的 别沦为口才的较量

BTW "JSF的架构师"这个我没有说清 我是指sun公司设计JSF的架构师

125 楼 icewubin 2008-04-26  

csf178 写道

解耦一直是架构中一个实践比较困难的设计原则
楼主一直在讲分层架构的解耦方式 显然也很认同
但是数据、逻辑跟表现之间还有纵向耦合 控件本身有一定独立性
至于究竟应该如何设计才能更好地解耦 就很难说了

所以至少JSF不是像你们说的那样一无是处
你不会认为JSF的架构师远远不如没事泡在这论坛的几个程序员吧？
就算差也差不了那么多对吧？

第一段你说得很好，我也没说JSF一无是处，我在讨论问题的时候更多的时候是从全局去把握，相对的考虑更多的非技术因素，因为非技术因素很多时候也很重要，比如我一直认为JSF有IDE的支持是一大优势，一直没有反驳过。所以没有说JSF一无是处，但是有些人没有仔细看别人写的东西而妄加评论就是非常不负责任了。

架构师应该同时应该掌握整个开发过程的效率，我也一直在说讨论是有前提的，当一个公司规模比较大，或者是开发技术已经由技术总监定下来了，或者是该公司得到SUN或者JBOSS的鼎力技术支持的，在这个情况下的架构师不管是主观的还是客观的都会利用公司的资源，用JSF组件做出各种优秀的设计。

一个公司对JSF技术投入有一年多，而且积累不少，对他们来说继续走这条路当然要比另起炉灶的成本要低得多。

以我们公司为例，之前很多程序员已经使用SpringMVC一年多，我也一直想换成Stuts2或者其他框架，但是切换成本非常大，考虑了很多因素，觉的这样的切换带来的效益远远不能抵消增加的投入，风险很大，就没有切换。而且本身我一开始刚进公司，对SpringMVC的理解也不够深刻。一段时间后比较深入的了解了它的优缺点，觉得也没必要急着切换，后来逐渐用了EXT配合MVC进行编程，在UI交互模式的简化过程中，SpringMVC承担的任务越来越少，使得当初想切换MVC框架的念头无限期的延后了。

当然你可以完全不理会这里的讨论，自己充分利用任何框架进行设计，但是不能在不了解其他框架实践的情况下随意的猜测别人的架构和应用方式，然后进行批判，这种猜测和批判是毫无意义的，而且多半都是和实际出入很大的。

124 楼 csf178 2008-04-26  

解耦一直是架构中一个实践比较困难的设计原则
楼主一直在讲分层架构的解耦方式 显然也很认同
但是数据、逻辑跟表现之间还有纵向耦合 控件本身有一定独立性
至于究竟应该如何设计才能更好地解耦 就很难说了

所以至少JSF不是像你们说的那样一无是处
你不会认为JSF的架构师远远不如没事泡在这论坛的几个程序员吧？
就算差也差不了那么多对吧？

123 楼 icewubin 2008-04-26  

fangshun 写道

“开发人员大量的时间用在UI开发和调试上”，我很赞同这句话，这就是我为什么选择jsf的主要原因，太多太多的事情你不用做了，你不用做了，不代表它不存在，jsf解决了，就应该记住，而不是因为它不好解决的事情而反对或者反感。

到底谁抢了谁的饭碗，现在来看B/S抢了C/S的饭碗，RIA想重新夺回，如果有那一天，我到完全可以接受，可你说了大家认可未来的RIA。而现在需要的是让RIA做它该做的事情，能做事情。目前我坚持认为维系两端的中间层开发模型，这个不可忽视的领域，jsf当仁不让！

我之前的长回帖请你先看过后再来和我讨论行不行，太多太多的事情你不用作了，那是需求还没有碰到变化，你是不是没有负责过项目啊，有时候一个从用户角度来说很平常的需求，客户也是人，客户平时也浏览网页，他们往往表述不清的时候，经常拿他们看到的网页和我们描述。举个真实的例子：客户说：“你们的搜索结果就不能高亮么，你看别人百度的搜索结果”，这种例子太多了，你认为JSF的组件都能满足么？

我没有说客户端框架是RIA啊，RIA一般是指客户端要装插件的，EXT这种不算RIA的，因为目前的RIA都不成熟，才用EXT，你知道为什么不成熟么？原因很多，引用robbin的一句话，目前的网页还是以dom或者说文字为主，以目前FLex技术的成熟度，开发效率是严重还达不到要求。

“目前我坚持认为维系两端的中间层开发模型，这个不可忽视的领域，jsf当仁不让！”你说这话本身就是有前提的，如果没有前提，我可以认为微软的解决方案比JSF的好得多。ROR的也很好啊。

122 楼 icewubin 2008-04-26  

fangshun 写道

spring的主要工作就是防止侵入，实现粘合，呵呵，这个粘合剂够多吧，seam干脆就叫缝合，和粘合就差一个字，难道胶合剂仅仅是一个客户端到服务端的传输线？？？做技术千万别提大老板啊，咱们不讨论那个，做好技术就OK，客户的体验我认为是其次的，满足实际业务需求才是最主要的，也是最致命的，满足实际需求的第一要诀就是适应需求变化，满足需求变化的第一要诀就是建立柔性的架构设计，好好想想全局怎么考虑问题吧，client技术和jsf相比，后者对于架构设计的协助要好的多，client模式只会降低架构设计的伸缩性，只能让设计与实现龟缩在client里面扑腾。

Spring还承担了持久层、事物层和MVC层的粘合剂，非侵入式的，这个我们讨论的有什么关系，我们没在讨论持久层和事物层。我们就是在讨论服务端和客户端通讯的问题，以下的一句很重要请注意：

从数据传送来讲：传统的写页面的方式就是利用servlet“写出”页面（同时还要写出各种客户端的逻辑）传送到客户端，每次都通过这种通讯方式高明么？

你说的“满足实际业务需求才是最主要的”当然是很对的，但是实在有限的时间和有限的人力情况下。“满足需求变化的第一要诀就是建立柔性的架构设计”，我怎么觉得你在帮我说话呢，我就是觉的JSF在客户端逻上非常不柔性啊。

client模式为什么会降低架构设计的伸缩性呢？难道fins说的你都没仔细看么？你在这里说话不是无理取闹么？请细看看fins的第一帖吧。

121 楼 icewubin 2008-04-26  

fangshun 写道

落后的始终是落后，进步的它就是进步，我就给你举举例子吧，myfaces标准实现后，apache基于myfaces出现的组件框架有Trinidad,Tobago,Tomahawk,Orchestra 等等，有一个是oracle捐赠的；基于模板重新定义渲染层的facelets框架，jboss公司出品的seam框架的重头戏就是增强jsf实践能力，增强jsf与业务框架的缝合能力，以及jsf的页面流程配置能力，richfaces，icefaces, ajax4jsf,都是jboss出的ajax的组件框架；金蝶的OperaMasks,包含了标准实现，ajax组件，seam功能很类似的增强框架IDE支持等等。sun基于netbeans的Visual JSF开发工具
Infragistics的商业jsf组件。等等........，我数不清了，你自己数吧！以前的框架能带来这样的连锁效应吗，怎么会是耦合性太高带来的产物呢？。老外都傻了吗啊，袁红岗技术认识很差啊！ 顺便你也说说基于struts都有什么扩展增强框架，别说的那么笼统，结合的不错，用xml作为纽带算集成吗，我用js通过ajax照样可以能让jsf基于request进行处理。

你凭什么说连锁效应就是耦合性低呢？微软的产品线长吧，耦合性低么？EJB的产品线远远超过你说的JSF的吧，耦合性低么？

我还懒得举客户端框架的连锁反应呢？事实情况是，反过来了，JSF为了迎合市场，要集成什么EXT。

我有说过用XML做为纽带么？除了XML客户端框架通讯和服务端通讯的方式有很种，json、buffalo、DWR等等，说起来我还反对用XML作为纽带呢。

IBM就有自己的一整套基于struts 1.x的增强扩展，我的同学在用的，infosis也有，别人用得好好的。

虽然你说：“我用js通过ajax照样可以能让jsf基于request进行处理”，如果大量的实践就是让JSF处理Ajax请求，我为什么还需要JSF呢？Stuts 2和Spring MVC的功能都足够了。

120 楼 icewubin 2008-04-26  

fangshun 写道

我不是走极端，这是一个明摆的事情，已经有很多人，在ajax上下大功夫了，我所知道的就有一个做表单的，表单上已经内嵌了所有需要的sql字段，通过client组装sql语句通过ajax发送给server端，多么轻松啊，多么解耦啊！server端的开发实践，开发模式你以为是做了一两年的毛头小伙提出来的，那是沉淀，client有吗？让我们继续造轮子，迟早有一天，ajax在客户端也有mvc框架的概念，呵，server端的mvc方向有问题，佩服！

你在举的这个例子的过程就是在走极端，我只认可好的客户端框架，我如果像你一样，举个下三滥的JSF框架来和你讨论，你觉得有意义么？

说到沉淀，CS结构MIS系统沉淀了几十年了，你怎么不去质疑沉淀了几十年的传统的两层结构的CS系统呢？

我现在认为server端的MVC方向有问题，就像我质疑EJB的作用一样，很正常么，有啥好佩服的？