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

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

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

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

你凭什么说连锁效应就是耦合性低呢？微软的产品线长吧，耦合性低么？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的功能都足够了。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- -！
没事 你们尽管说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，为什么每次版本升级变化这么大？据我微软的同学说，好像是微软内部技术派系斗争的结果。是不是如此呢？

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

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

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

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