放弃seam
 |
眯着眼的老狼
2009-05-17
好久没来这里了。早就想说说对seam的部分看法，可一直累得不想动。
今天闲着，就乱说说吧。虽然在软件开发领域，我已经是个老头，但07年秋才开始转用java，所以观点可能荒唐，大家尽管批评。 原来的在微软体系下的很多积累都浪费了，很心痛。所以转向java后，确定系统架构、开发工具，考虑得非常慎重。经过大量学习和向朋友请教后，基本决定采用jsf+jpa。一个偶然，让我知道了seam，迫不及待地去认识它，seam解决了jsf不少不方便的地方，加上对Gavin King的崇拜，决定改用seam。 经过半年多的开发，07年7月，发布了第一个用seam 2.0开发的管理系统。由于访问压力较小，所以已经使用了一年了。 这个系统应用之前，我忙得没空对它进行压力测试，可自己感觉，seam性能不佳。随后要开发的系统，访问压力要大得多，我不得不重新审视seam。 首先，我做了一个非常简单的bean，非常简单的view，在sun jsf与jboss seam下进行对比压力测试，结果让我大吃一惊，seam比sun jsf慢很多，view越复杂，相差就越多，我记得稍微复杂的view，居然会相差20倍之多。因为bean非常简单，这是纯粹对view呈现性能的测试。 之后我放弃了seam，回到了jsf+facelets+jpa的体系中去，已经有近一年的时间。我的应用系统，jsf+facelets+jpa足够了，性能上明显要比seam要好得多。针对jsf的一些弊端，我进行了一些扩展或其它的手段解决，也克服一部分，感觉也很得心应手了。 嘿嘿，回过头再回味seam，真的没觉得现在的seam有啥值得炫耀的。也许将来seam会不一样。 做软件研发这么多年，虽然没赚到什么钱，但感受挺有意思的。最郁闷的就是，这世界变化太快，总担心落伍，担心愚蠢，年纪越来越大，更害怕被抛弃。没工作才是最可悲、最可怕的。 大言不惭，目的是向大家学习。 |
 |
duker
2009-05-17
web 应用传统的模式是状态服务器端管理,浏览器只负责接收生成的html/css/js 这种模式下有两种类型的框架,mvc类型的框架和组件类型的框架.对于简单的应用mvc框架足够了,对于界面复杂,交互逻辑复杂的情况,组件框架更适合一些. 服务器端组件框架java 领域只有jsf 和wicket,(tapestry 是挂羊头卖狗肉).要说易用性,jsf根本和wicket没法比..
现在新一代ria 的模式是状态管理向浏览器客户端转移,有几种解决方案, flex, javafx, silverlight, gwt. silverlight 不用考虑了,一些大客户弃sl选flex 已经说明了一切. javafx 起步太晚,并且sun被收购,所以前景不明朗. 剩下的gwt 和flex 是比较有前途的两种方案. flex 目前胜在丰富的矢量图形效果,最佳的流媒体支持. gwt 胜在和浏览器标准一脉相承. 有意思的是,二者都是可以灵活使用的技术,而且不是完全互相排斥. 个人更为看好和喜欢gwt. |
|
眯着眼的老狼
2009-05-17
谢谢duker指点
|
|
duker
2009-05-18
呵呵,指点谈不上,只是自己的一点总结,希望是正确的和对你能够有帮助.
|
|
眯着眼的老狼
2009-05-18
duker:
你好！ 我通过这张很经典图，远远地看了下wicket，确实挺有意思。但我很吃惊你说jsf和wicket没法比，因为我觉得jsf挺不错的。 http://www.breakitdownblog.com/wp-content/uploads/2007/05/wicket_vs_jsf_forum.png 我更乐意采用纳入到规范的JSF，一方面降低开发积累浪费的风险，另一方面容易招到有一定经验的开发人员。 至于ria，好几年前就考虑过flex，但这方面的人才太少了，也意味着成本会吃不消。 等空了，去仔细了解wicket。 很高兴和你交流，也希望以后常交流。谢谢。 |
|
duker
2009-05-18
可能用词有些不当,呵呵..
jsf 虽然也是组件模型,但视图需要用jsp 和一套tag来创建,或者使用facelet这样的东西..而且还有xml配置文件. 这意味着开发jsf的项目时,大脑要在不同的context之间切换. 而我们都知道,切换是有成本的.  wicket里面一切都用java 代码搞定, html模板被设计到最简--使用一个attribute表示某个标签是wicket组件. 所以开发时专心写java代码就可以了. 而且wicket的组件模型也要比jsf的组件模型简单---开发自己的组件更容易一些. 至于你说的标准问题,可能各人的看法不同,如果是我选的话,我更愿意选wicket,如果是新手,当然简单的东西更容易掌握一些. 也希望能和你经常交流,我的qq: 517655261 |
 |
dengyin2000
2009-05-18
我想补充一点， tapestry5 比 wicket更优雅。 还有性能。
|
 |
wangyu4882
2009-05-19
引用 我更乐意采用纳入到规范的JSF，一方面降低开发积累浪费的风险，另一方面容易招到有一定经验的开发人员。 此言差矣，我最近在招聘JSF，SEAM的人员，熟悉的人不多。或者成本很高。 JSF自定义组件太复杂，JSP+XML+2-3个java文件，还不如JSP TAG简单。JSF不知不觉就当成了Structs2来用。 SEAM配置文件一堆，而且Seam+Jboss的开发环境巨吃内存。 jSf不利于美工的工作，有几个美工会写facelet，会自定义JSF组件的？ 除非客户要求，我个人是不会选择JSF，SEAM开发的。 |
|
duker
2009-05-19
服务器端的组件模型框架肯定是比mvc框架吃内存的,要避免这个问题,只有简化服务器端的状态管理--使用mvc或者采用ria 方案.
|
|
jef
2009-05-19
首先我得声明，我没有用过jsf,seam,gwt。。。我只用过ext js,flex。html,css,js都会写一些。
我觉得在bs架构的应用里面，b这一端本质上就是html,js,css，还有第四种吗？没有了。最多加个flex。 其他无论啥技术最后不是都得翻译成浏览器这边的html,js,css吗。 我觉得让服务器端过多的控制浏览器端的显示输出是个吃力不讨好的活。有这功夫干嘛不好好研究研究js,css什么的呢？非要用一些后台的组件框架？越搞越复杂。 不怕笑话，其实我连后台的标签tag都不用，因为那是浏览器识别不出来的标签。组件标签用得越多，就越觉得那不像是个页面。。。 试问，如果一个做后台开发的程序员同时熟悉html,css,js，或者学习html,css,js的学习曲线，花费的时间并不像想象的高，那这些服务器端组件框架的优势在那里？ 看你们说的这么复杂，我胡乱说几句。没有冒犯各位的意思，我只是说下自己的想法。欢迎批评指正。 |
