做JSF很久了，小弟我也说说JSF的缺点
日期：2014-05-16 浏览次数：29381 次
看了论坛上最近关于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的。
?
如果你用richfaces特别是其ajax特性。
非常好用。
你写一个项目能用多少种方法写页面？
另一条路是从js 学起，一路上css、prototype、ext等等，学习成本也不低啊。
richfaces的ajax部分就是以前的ajax4jsf，确实做得不错。richfaces的很多组件做的也很强大，但是……
- 我觉得richfaces的皮肤太难看了，虽然提供了很多个skin，但是没一个好看的，当然按照jsf说秉承的优良传统，richfaces的皮肤也是可以自定义的，文档也挺详细，但是那么多的样式，自定义太难。
- 组件虽然多，但不灵活。richfaces挺强大，组件很丰富，但是你会发现这么多组件还是有很多问题解决不了，需要自定义组件，这说明了什么？这是否意味着不管什么东西都用组件来封装的做法本身是不是有问题呢？何况随着组件库的膨胀，学习的难度和成本就会很高。
这一点通过一个例子和wicket（或Tapestry）对比一下。比如你想实现一个复杂表头且固定表头的table，你用jsf的table怎么办呢？我觉得不太好做。richfaces怎么做呢?他提供了一个复杂的table组件，你可以通过设置一堆的属性来合并单元格之类的拼出一个复杂的表头来。而要用wicket甚至jsp（jstl）你的表头用html作就可以了，怎么加js、css都随便吧，你在dreamweaver里做出来就可以了。
这只是一个例子而已，你会看到在jsf的世界里，会充斥这各种各样类似的组件，比如一个table会有n个厂商提供属性各异功能各异的组件，但好像没有一个好用的。
我们现在的项目都是基于JSF的
