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

建议还是看看SEAM的DEMO代码，无须配置JSF组件，加上annomation就可以把一个POJO做为SESSION BEAN，完全做到跟RAILS的controller一样简洁明了。facelets甚至不用编译。我们现在的团队基本上没有JSF经验，却也两个月内写完了项目，但到现在也只是初步了解JSF的几个常用TAG而已。 唯一的缺点也就是慢点而已。

我完全不懂JSF，不过看完之后就想去看一下JSF。


不一定非得UI厂商才有必要自行开发UI组件的，有时为了实现一些比较特殊的复合组件，也是需要自行开发的，不过量不能多，而且要保持简单，可维护。

另外，解耦问题，前台的东西，我就一直保持在Apache上开发，数据都mock好，写了一个小东西来组装js，最后会用Ant打个包，顺便跑跑testcase，然后丢进需要的项目里。后台只管拿到什么请求就做什么处理，然后输出。不知道这算松还是紧。

都这么多讨论了呀，别的不说什么，我一个朋友，也是javaeye的会员，他做了很久的JSF，现在天天告诉我说多烦JSF，哈哈哈哈。

还是那句话，我喜欢纯粹的js。

我还是决定研究一下jsf  不过它的架构注定了它不可能是我期望的那种B和S松耦合的系统.
我之所以决定研究一下是为了当反对它时让自己的底气更足.

其实任何技术都有好的一面也有不好的一面 各取所需也许就已足够

过多的争论只能让"技术辩论"沦为"口才的较量", 最后不仅谁都无法説服谁 反而伤了和气.

不过 不管怎样 我一直坚持的我想法,也许这种想法确实很理想主义 很不现实
但是我依然坚信 未来的B/S应该会离我的想法越来越近的.
解偶 是软件设计里 永恒的主题. OO OOA OOD WS SOA REST...这些东西背后的思想都离不开"解偶"二字.

期待 fins 研究jsf後給大家提供精彩的解答

我觉得JSF有以下的缺点：
1.学习曲线高。也许你会说只有组件开发人员才需要深入了解JSF的声明周期和高级的东西，普通开发人员不需要学习那么多——但是随着开发的深入，你马上就会发现必须要学习这些深入的东西，否则你只能写出呆板和充满隐患的程序。

2.OO。JSF是基于组件事件驱动的，也许你觉得他很像Swing，但其实也很像struts。对于熟悉action base的开发人员可能不太熟悉他的OO方式，而喜欢OO的开发人员反而又觉得它不够OO（还不如Wicket，Tapestry）。——而且OO的人少，都是用OO的工具语言做非OO的事情，不信看看好多JSF写的程序，写着写着就写成了struts，甚至还不如。

3.写一个自定义组件太难。

4.灵活性不够。组件库本来就不够丰富，想实现一个复杂表头？想物理分页?你得找到相关的组件，往往发现这个组件满足你的这个要求，却满足不了那个需求，而满足了那个的又满足不了这个。实在没办法，就得自定义。如前所述，自定义组件有很难，尤其是一个有很多功能的组件。还有就是和其他工具的集成——想用FCKEditor吗？想用一个Office插件吗？想用数字签名的插件吗？找JSF组件吧，没有的话就自定义吧。而action base的MVC框架在这一点上就容易的多。

5.东西太多太乱。要想用好JSF，你的用几个第三方组件库吧——RichFaces，ICEFaces……看看那些组件的属性吧，想短时间弄清楚也够费力的，何况你还得知道他们用了那些css的class……，你还的用facelet吧，甚至Seam也用上……关键是乱七八糟的东西放在一起缺乏一以贯之的统一性。

6.也许IDE可以拯救JSF……也许吧，现在还看不到希望，要是能做出杀手级别的，应该早就做出来了吧……JSf都好几年了。

7.性能不好。做过企业应用或许还凑合吧，但性能确实不好。把manager bean放在session中性能不好，不放的话，你发现你写程序时又像是action base了，甚至还没有action base方便。而不是像教程上那样的OO，因为教程上的例子都是把manager bean放在session中，而且table也是内存分页，所有数据放在一个list中，最终在放在session中——程序确实很OO，但……。

推荐喜欢action base的或页面和性能要求较高的用springmvc和webwork，喜欢组件话事件驱动的用wicket吧。

不过JSF也有一个优点，就是对工具相对较友好——我最近做一个可视化的表现层的产品用的是JSF，这一点体会还很深的，当然我自己做开发的话是不会用JSF的。

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

讨论来讨论去，我觉得我们的视野是否望外看一下，我想那就是RIA。Flex，AIR，Siliverlight,JavaFX我想应该是最好的客户端技术。

我们项目因为客户的架构师强制要求，使用了JSF。就发现JSF控件的状态是序列化到了字符串中存在了页面里。这就造成了，这个状态无法在客户端被修改。想用JS给table加一行？门都没有。最后无奈，只能把JSF当成JSP用，制作渲染。所有的提交都走了AJAX。。。另外JSF的AJAX控件，真的很烂。

我管那分层，设计原则，实现了就行