2007-04-19
Java Web层的下一个王者是谁？
关键字: web framework
经过数年的“框架大战”，Java界的各种框架找到了自己应有的位置。
Spring+Hibernate+Struts已成为Java开发的主流体系。在这个体系中，Spring+Hibernate的地位应该说短期内是难以撼动了。除了新兴的Jboss Seam作为挑战者之外，几乎难有劲敌。有趣的是当初Spring、Hibernate作为挑战者，将官方的EJB成功挑落马下；这次反倒是官方的EBJ3成了挑战者，不知结局如何。
Java B/S编程中历来战火最激烈的其实还在Web层，框架的数量最多，争议最大。
一切由Struts而起，而Struts最终也坐稳了第一个时代的王座。在技术层面，Struts 1.x已经被无数人抱怨过、批评过，但终于还是稳坐王位，这充分说明了习惯的力量。“稳定压倒一切”，这句话在IT技术领域仍旧适用。
其实IT应用技术，什么新鲜玩意并不难学。难的是标准化和规范化。每个程序员都有自己的思路和习惯，写出来的代码自然是五花八门。Java何以成为编程界的老大，很重要的一点在于Java的规范化。这种规范化很高的语言适用于多人合作的大型项目，便于沟通和理解，也就便于集成和维护。Java世界为什么会框架横飞，说到底还是规范化的需要。纯JSP和Struts写Web谁快，摆明了是JSP。那撑饱了用Struts？原因在于100个人写出来的JSP，有100种写法；而100个人写出来的Struts，基本相似。Struts之成功，正缘于其在Java Web层的规范化方面所做出的贡献。
然而长江后浪推前浪，Struts 1.x的技术缺陷毕竟是隐患。
Sun力推JSF，打算一雪Web层框架缺失之耻。可惜JSF既要沿用Swing的技术路线，又要学ASP.NET，还要照顾产商的IDE，结果搞了个四不象，弄得里外不是人。当然Sun的技术实力毕竟是超强的，只要别重蹈EJB的覆辙，拿出点专断的精神（像这两年的NetBeans），做出像Swing那样水准的东西，JSF当大有作为。JSF现在比较有优势的是对Ajax的集成，这一点走在了其他框架的前面。
而Struts就更没有志气了，把WebWork换了个标签，凑出个Struts2，Bug多多。说实在话，根本不如原版的WebWork。如果不是靠了原先的fans捧场，根本就没得混。不过Struts原本就不是以技术取胜的，靠的是抢占先机带来的习惯优势。如果原先的fans们在这两年内都能转到Struts2，那么Struts二世仍将雄霸天下。
综上所述，未来两年，JSF与Struts将展开Java Web框架的最终战争。
以笔者愚见，结局有二：一是不论Struts还是JSF获胜，Java Web层都将结束混战的局面，这对Java Web开发的标准化是非常有利的，并有助于巩固Java在B/S界的地位；二是Struts1.x、Struts2、JSF三分天下，必然从整体上削弱Java在B/S界的竞争力，并将进一步被RoR、ASP.NET、PHP所蚕食。
有兴趣者参加讨论。
Spring+Hibernate+Struts已成为Java开发的主流体系。在这个体系中，Spring+Hibernate的地位应该说短期内是难以撼动了。除了新兴的Jboss Seam作为挑战者之外，几乎难有劲敌。有趣的是当初Spring、Hibernate作为挑战者，将官方的EJB成功挑落马下；这次反倒是官方的EBJ3成了挑战者，不知结局如何。
Java B/S编程中历来战火最激烈的其实还在Web层，框架的数量最多，争议最大。
一切由Struts而起，而Struts最终也坐稳了第一个时代的王座。在技术层面，Struts 1.x已经被无数人抱怨过、批评过，但终于还是稳坐王位，这充分说明了习惯的力量。“稳定压倒一切”，这句话在IT技术领域仍旧适用。
其实IT应用技术，什么新鲜玩意并不难学。难的是标准化和规范化。每个程序员都有自己的思路和习惯，写出来的代码自然是五花八门。Java何以成为编程界的老大，很重要的一点在于Java的规范化。这种规范化很高的语言适用于多人合作的大型项目，便于沟通和理解，也就便于集成和维护。Java世界为什么会框架横飞，说到底还是规范化的需要。纯JSP和Struts写Web谁快，摆明了是JSP。那撑饱了用Struts？原因在于100个人写出来的JSP，有100种写法；而100个人写出来的Struts，基本相似。Struts之成功，正缘于其在Java Web层的规范化方面所做出的贡献。
然而长江后浪推前浪，Struts 1.x的技术缺陷毕竟是隐患。
Sun力推JSF，打算一雪Web层框架缺失之耻。可惜JSF既要沿用Swing的技术路线，又要学ASP.NET，还要照顾产商的IDE，结果搞了个四不象，弄得里外不是人。当然Sun的技术实力毕竟是超强的，只要别重蹈EJB的覆辙，拿出点专断的精神（像这两年的NetBeans），做出像Swing那样水准的东西，JSF当大有作为。JSF现在比较有优势的是对Ajax的集成，这一点走在了其他框架的前面。
而Struts就更没有志气了，把WebWork换了个标签，凑出个Struts2，Bug多多。说实在话，根本不如原版的WebWork。如果不是靠了原先的fans捧场，根本就没得混。不过Struts原本就不是以技术取胜的，靠的是抢占先机带来的习惯优势。如果原先的fans们在这两年内都能转到Struts2，那么Struts二世仍将雄霸天下。
综上所述，未来两年，JSF与Struts将展开Java Web框架的最终战争。
以笔者愚见，结局有二：一是不论Struts还是JSF获胜，Java Web层都将结束混战的局面，这对Java Web开发的标准化是非常有利的，并有助于巩固Java在B/S界的地位；二是Struts1.x、Struts2、JSF三分天下，必然从整体上削弱Java在B/S界的竞争力，并将进一步被RoR、ASP.NET、PHP所蚕食。
有兴趣者参加讨论。
- 17:47
- 浏览 (31975)
- 论坛浏览 (37900)
- 评论 (95)
- 分类: Java
- 相关推荐
评论
xianlv 写道
无聊。
哪个简单用哪个，哪个“便宜”用哪个。
MVC框架所谓的“框架大战”，没有太多的实际意义。我觉得即便是 jsp +javabean,也足够应付大部分web项目了。
我问过很多人，为什么要分层，为什么要自找麻烦弄一堆的配置文件，得到的回答往往感觉比较教条。
我比较同意白衣在某个跟贴中提到的：Annotation + Convention 是趋势。
Convention是意识形态问题
Annotation是语言能力所限。其实很多号称“配置文件”的，根本就不是配置文件(web.xml,log4j.xml是配置文件，而象struts-config.xml不是在做所谓的“配置”)，而是因为先前的Java语言没有那个能力，所以才额外搞一堆麻烦。现在有了语言利器，再写配置文件，无异于脱裤放屁。
扯的远了，大概意思，就是无论什么框架，只要简单、便宜就好；没有框架，事情能搞定也可以。
哪个简单用哪个，哪个“便宜”用哪个。
MVC框架所谓的“框架大战”，没有太多的实际意义。我觉得即便是 jsp +javabean,也足够应付大部分web项目了。
我问过很多人，为什么要分层，为什么要自找麻烦弄一堆的配置文件，得到的回答往往感觉比较教条。
我比较同意白衣在某个跟贴中提到的：Annotation + Convention 是趋势。
Convention是意识形态问题
Annotation是语言能力所限。其实很多号称“配置文件”的，根本就不是配置文件(web.xml,log4j.xml是配置文件，而象struts-config.xml不是在做所谓的“配置”)，而是因为先前的Java语言没有那个能力，所以才额外搞一堆麻烦。现在有了语言利器，再写配置文件，无异于脱裤放屁。
扯的远了，大概意思，就是无论什么框架，只要简单、便宜就好；没有框架，事情能搞定也可以。
同意;Annotation + Convention 是趋势;
jsp+javabean用得好,也很不错的,但问题是怎样规定项目组成员写代码的风格,使大家都容易明白,用框架搭建写出来的代码,大家都差不多的,容易理解,容易看一些.
无聊。
哪个简单用哪个，哪个“便宜”用哪个。
MVC框架所谓的“框架大战”，没有太多的实际意义。我觉得即便是 jsp +javabean,也足够应付大部分web项目了。
我问过很多人，为什么要分层，为什么要自找麻烦弄一堆的配置文件，得到的回答往往感觉比较教条。
我比较同意白衣在某个跟贴中提到的：Annotation + Convention 是趋势。
Convention是意识形态问题
Annotation是语言能力所限。其实很多号称“配置文件”的，根本就不是配置文件(web.xml,log4j.xml是配置文件，而象struts-config.xml不是在做所谓的“配置”)，而是因为先前的Java语言没有那个能力，所以才额外搞一堆麻烦。现在有了语言利器，再写配置文件，无异于脱裤放屁。
扯的远了，大概意思，就是无论什么框架，只要简单、便宜就好；没有框架，事情能搞定也可以。
哪个简单用哪个，哪个“便宜”用哪个。
MVC框架所谓的“框架大战”，没有太多的实际意义。我觉得即便是 jsp +javabean,也足够应付大部分web项目了。
我问过很多人，为什么要分层，为什么要自找麻烦弄一堆的配置文件，得到的回答往往感觉比较教条。
我比较同意白衣在某个跟贴中提到的：Annotation + Convention 是趋势。
Convention是意识形态问题
Annotation是语言能力所限。其实很多号称“配置文件”的，根本就不是配置文件(web.xml,log4j.xml是配置文件，而象struts-config.xml不是在做所谓的“配置”)，而是因为先前的Java语言没有那个能力，所以才额外搞一堆麻烦。现在有了语言利器，再写配置文件，无异于脱裤放屁。
扯的远了，大概意思，就是无论什么框架，只要简单、便宜就好；没有框架，事情能搞定也可以。
lgx522 写道
经过数年的“框架大战”，Java界的各种框架找到了自己应有的位置。
综上所述，未来两年，JSF与Struts将展开Java Web框架的最终战争。
以笔者愚见，结局有二：一是不论Struts还是JSF获胜，Java Web层都将结束混战的局面，这对Java Web开发的标准化是非常有利的，并有助于巩固Java在B/S界的地位；二是Struts1.x、Struts2、JSF三分天下，必然从整体上削弱Java在B/S界的竞争力，并将进一步被RoR、ASP.NET、PHP所蚕食。
有兴趣者参加讨论。
综上所述，未来两年，JSF与Struts将展开Java Web框架的最终战争。
以笔者愚见，结局有二：一是不论Struts还是JSF获胜，Java Web层都将结束混战的局面，这对Java Web开发的标准化是非常有利的，并有助于巩固Java在B/S界的地位；二是Struts1.x、Struts2、JSF三分天下，必然从整体上削弱Java在B/S界的竞争力，并将进一步被RoR、ASP.NET、PHP所蚕食。
有兴趣者参加讨论。
guoshiguan
2007-05-21
回复
林秋枫 写道
JSF就是一种初级开发人员叫着爽（因为用IDE拖拉很容易），维护人员看着烦（视图代码杂乱无条理），客户等着骂娘（大量UI事件，页面反应太慢）东西而已...
jsf也没有那么可怕吧，很多事情是你设计的时候的问题，
看过一篇对JavaWebFramework比较的文章，JSF好像比Struts2，webwork更好，但JSF我没接触过不多加评论。我的感觉，Struts2简直是Webwork，而非struts1.x的升级！
raining_cn
2007-05-11
回复
感觉还是webwork，现在的struts2说到底就是webwork2，jsf技术不是太成熟。不过也希望jsf能有大的提高。做的跟asp。net那样就爽了。
exceedsun213
2007-05-08
回复
说实话，刚开始用JSF做开发时，的确有些不适应，无法控制局部细节，以前的许多开发经验不但用不上，有时反而帮倒忙，但不久就会发现他的优点，开发速度，维护，的确是比原来有很大提高（至少比struts是这样）。当然每个人的感觉都是不同的，也不用强求，好不好不必急于下结论，我用他做开发将近一年了，感觉JSF绝对是一个值得学习的技术。配合ajax4jsf开发出的应用，会使自己都大吃一惊。
exceedsun213
2007-05-08
回复
JJYAO 写道
Good!非常同意
抛开低层的技术实现不谈，一个框架的生命力，或者可接受程度很大程度上也取决与如何与现存的技术能够比较平滑的过度
我本人非常期待
1. JSF能与JSP混合编程(可能几乎不可能，JSF tag和JSP tag的生命周期和完成的功能都有很大区别)，使老系统能够比较平滑的过度到JSF
2. MyFace整合和adface后能够统一开源的JSF实现，将tobargo,tomahawk,adface集成在一个实现中,提供更强大的组件类库
JSF是可以与JSP混合使用的
J2EE5的卖点之一就是JSF1.2和JSP2.1
现在咱们讨论的JSF一般都是JSF1.1的标准
即使不用JSF1.2，使用优秀的facelets框架也可以做到JSP、JSTL、JSF的混合使用
http://www.google.com/trends?q=JSF%2CTapestry%2CSpring+MVC&ctab=0&geo=all&date=all
问问Google Trends，也许能够说明一些问题
问问Google Trends，也许能够说明一些问题
JSF从2005年就开始使用了,个人感觉还不错,web层这些东西用啥用顺手了都可以,何必强求呢，任何Ｗｅｂ框架，包括ＪＳＦ都不实很复杂，且都有缺点，技术这东西似乎永远没有完美的！
一开始喜欢Tapestry,但Tapestry5出来之后，发现跟Tapestry4不兼容，而且Tapestry5要到今年秋季才成熟。于是退而观望之。
Spring MVC 不错，但没有用来做过大项目。
Spring MVC 不错，但没有用来做过大项目。
to leebei
RIA其实可以对搜索引擎友好的，微软的SilverLight就可以，因为是纯xml不须编译的，这也是微软的一个卖点。
adobe的flex目前不行，但以后可能也会增加这方面的支持。
openLaszlo可以生成swf，DHTML，等多种目标文件，你如果选择生成DHTML，问题也就不存在了。
RIA其实可以对搜索引擎友好的，微软的SilverLight就可以，因为是纯xml不须编译的，这也是微软的一个卖点。
adobe的flex目前不行，但以后可能也会增加这方面的支持。
openLaszlo可以生成swf，DHTML，等多种目标文件，你如果选择生成DHTML，问题也就不存在了。
to dlee:
同意你的大部分观点，RIA不可能适用所有的应用场合，这点我也意识到了，比如需要搜索引擎友好的内容服务页面（比如CMS阅读端），就不适合用RIA技术实现。
对这个：
...前几天在一个活动上我遇到一位朋友，他们就需要用同一套Web应用同时支持桌面电脑的浏览器和各种手机的浏览器。。。
除非应用本身非常简单，我认为这个要求有问题：手机的屏幕大小、输入接口限制决定了它不能胜任复杂界面应用，要一套应用同时支持pc与手机，其结果只能是简化pc下的UI操作，影响桌面用户的工作效率。比如哪天javaeye要同时支持手机用户，我估计站长们一定会单独为手机设计一个前端，而且一般也不会提供目前桌面版本的所有功能。
补几句：想起来某些大厂商所反复宣传的，它们的Portal系统如何先进，能为不同的客户终端配置同一个应用的不同界面，对此我一直都认为是很无聊的忽悠，一笑了之。客户很多时候基于感性认识一个产品，而我们作为开发者应该比客户思考得更多。
同意你的大部分观点，RIA不可能适用所有的应用场合，这点我也意识到了，比如需要搜索引擎友好的内容服务页面（比如CMS阅读端），就不适合用RIA技术实现。
对这个：
dlee 写道
...前几天在一个活动上我遇到一位朋友，他们就需要用同一套Web应用同时支持桌面电脑的浏览器和各种手机的浏览器。。。
除非应用本身非常简单，我认为这个要求有问题：手机的屏幕大小、输入接口限制决定了它不能胜任复杂界面应用，要一套应用同时支持pc与手机，其结果只能是简化pc下的UI操作，影响桌面用户的工作效率。比如哪天javaeye要同时支持手机用户，我估计站长们一定会单独为手机设计一个前端，而且一般也不会提供目前桌面版本的所有功能。
补几句：想起来某些大厂商所反复宣传的，它们的Portal系统如何先进，能为不同的客户终端配置同一个应用的不同界面，对此我一直都认为是很无聊的忽悠，一笑了之。客户很多时候基于感性认识一个产品，而我们作为开发者应该比客户思考得更多。
smilelee74
2007-04-30
回复
要是有个框架能实现JSP的继承就好了。
这个应该是能实现的，本来servlet是可以继承的
这个应该是能实现的，本来servlet是可以继承的
libai 写道
简单举几条：
1、IE4的事件模型基本完善，事件种类和可发生事件的元素远多于NN4/5。
2、IE4可以真正的动态改变几乎所有的HTML元素，而NN4/5只是用LAYERs模拟出一些简单的动态效果，并非真正的DHTML。
3、IE4的TextRange可控制性远好于NN4/5。
4、IE4独有数据岛绑定元素，这是早期富客户端实现的重要技术之一。
5、IE4的Filters/Transitions效果和可script操作性都比NN4/5强不少。
例子可能没有直观的说服力，你只要将ie4和nn4/5的API Refrence手册摆在一起，数数它们的页数，就可以将它们分出高下了。
1、IE4的事件模型基本完善，事件种类和可发生事件的元素远多于NN4/5。
2、IE4可以真正的动态改变几乎所有的HTML元素，而NN4/5只是用LAYERs模拟出一些简单的动态效果，并非真正的DHTML。
3、IE4的TextRange可控制性远好于NN4/5。
4、IE4独有数据岛绑定元素，这是早期富客户端实现的重要技术之一。
5、IE4的Filters/Transitions效果和可script操作性都比NN4/5强不少。
例子可能没有直观的说服力，你只要将ie4和nn4/5的API Refrence手册摆在一起，数数它们的页数，就可以将它们分出高下了。
IE4对于DHTML的支持更好，这个我同意你的观点，也同意这个是使得Netscape4退出市场的一个非常重要的因素。不过现在争论这些大约10年前的技术已经没有很大的意义。
我反对你的一个观点是，你似乎认为将来Web表现层无论何时都应该前推到浏览器端来做，由浏览器端的JavaScript来完全控制用户的整个工作流程。这种解决方案其实是一类“one-size-fits-all”的解决方案。
我曾经与朋友讨论过，在什么场合下，事件模型必需要放在服务器端来处理？因为WPF和Apollo等RIA技术可以把事件模型完全放在客户端，与用户相关的状态也完全保存在客户端。我们经过讨论之后，认为其实还是有一些场合需要在服务器端处理事件模型的，当然状态也保存在服务器端。所以还是要具体问题具体分析。
另外你的方案完全用JavaScript来控制用户的整个工作流程，假如用户的浏览器不支持JavaScript，整个应用就会完全失效，或者需要对应用的架构做很大的改动。这种情况确实是存在的，前几天在一个活动上我遇到一位朋友，他们就需要用同一套Web应用同时支持桌面电脑的浏览器和各种手机的浏览器。手机中的浏览器仅支持WML，完全不支持JavaScript，更不用说XMLHttpRequest。他们是在服务器端使用Struts+XSLT来解决的这个问题。另外，一些浏览器的插件（例如Firefox有一个插件叫做“NoScript”）会将浏览器对于JavaScript的支持禁止掉。同时支持各种能力不同的浏览器叫做“Graceful Degradation”，做到这一点，可以提供更好的Web可用性。有一种Ajax应用的开发过程叫做Hijax，可以很好地支持“Graceful Degradation”，开发出来的Ajax应用即使在不支持JavaScript的浏览器中也不会影响到基本的功能，只是退化为一个传统的Web应用。这种技术在即将出版的Bulletproof Ajax中文版中有介绍。
发表评论
该博客是同时发布到论坛的，无法评论在论坛已被锁定的帖子
lgx522
最新评论
-
OO和SQL，应该携手共进
世界本来就是一个平衡体， 分析问题也要如此心态
-- by spiritfrog -
OO和SQL，应该携手共进
本来就是如此，各有所长嘛!
-- by hatedance -
Spring性能小测，参其它技 ...
laiseeme 写道hibernate没问题 有问题的是用hibernate的 ...
-- by xellos -
Spring性能小测，参其它技 ...
王者之剑 写道我觉得这个贴子应该成为精华贴， 如果将这类问题老是搞得看不见的话， ...
-- by davidcen -
Spring性能小测，参其它技 ...
jander 写道icewubin 写道williamy 写道 2。上面谁说OR ...
-- by icewubin
评论排行榜