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

晕倒，你对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稍有逊色。但这不是攻击它的理由。如果你非要跟我将效率，我并不反对你拿汇编写你的程序，这个跟我无关！呵呵

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

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

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




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

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

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

InputStream.read()

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

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



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

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

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

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

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

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

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

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端的技术框架呢?



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


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


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

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

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

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

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

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

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

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

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

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