http://blog.youkuaiyun.com/john_zhu/archive/2005/07/10/419248.aspx
Web Framworks 的决斗
译者:John Zhu
在本次JavaOne的周三的对话中,关于Web 框架的对决是非常有趣的对话之一。我们从这次对决的拥护者和格式开始报道,我们提供每个框架的概要描述和不同点,最后,我们发布TSS的自己的积分卡,那个框架在本次决斗中倒下,以及"Best Business Case" 和 "Best Technical Case"的胜利者。
决斗的拥护者:
参与的框架:
JavaServer Faces, championed by Ed Burns
Webwork, championed by Jason Carreira
Shale, championed by David Geary
Tapestry, championed by Howard Lewis Ship
Wicket, championed by Eelco Hillenius
缺席但是非常优秀的其他框架:
Struts 1.x
SpringMVC
Ruby on Rails
决斗的方式:
第一回合: 每个拥护者用三分钟介绍他们的框架.
第二回合: 主持人提问.
第三回合: 观众提问.
战斗的钟: 主持人是Kevin Osborn控制着战斗的钟声.控制现场秩序,以利于决斗不会使用非正当手段或者拥护者是否超过时间时.
我们的评论:
我们注意到在本次决斗中一个主要的趋势是针对组件。每个框架介绍自己的Web组件如何工作的优势。传递给观众的信息是web组件是如此的流行和时兴…拥护者介绍他们的组件的核心在于看上去像什么?我们还注意到,Struts已经明显落后,而所有其他的框架都努力在从Struts的阴影中突破,强调自己如何之不同和如何之更好。尽管Web框架已经前进并将Struts丢在后面,但是Struts仍然是经过实践检验并在成千的成功项目中实施。我们禁不住认为Structs没有包含Web组件的思路,所以开发者需要考虑其他的框架,web组件是一个好的开始。:)
框架概述 (第一回合)
JavaServer Faces (JSF)
- 技术特性
- 界面接口组件和事件模型的第一个类
- POJO依赖注入(又称控制反转)
- 客户端独立性
- 使用或者不使用工具
- 可扩展的导航(类似于Struts导航,注:Page导航)
- 强大的扩展能力 (如Shale)
- 完全的集成(如JSP集成Spring)
- 本地化和易理解性
- 界面接口组件和事件模型的第一个类
- 市场和商业特性
- 广泛的采用,包括SUN,Oracle,IBM,BEA,Apache,EDS
- 作为J2EE 5.0的部分
- 大型第三方组件市场(iLog, Business Objects, Oracle, Sun, IBM)
- 业内领先的工具支持(Sun Java Studio, Oracle JDeveloper, IBM WSAD, NitroX plugin for Eclipse, Exadel Studio)
- 已经有关于JSF的许多的书上架了
- 在Monster上三页长的关于JSF的工作需求
- 广泛的采用,包括SUN,Oracle,IBM,BEA,Apache,EDS
Webwork
- 核心价值
- 简单
- 可测试
- 可维护
- 可扩展
- 简单
- 对于未知展示层技术的支持,这次JSP,Velocity,和其他的展示层技术
- 对于Http请求映射未逻辑(交互性)活动
- 通过分层的MVC和模板机制简化组件
Shale
- 集成JSP和Jakarta的框架
- 成为Struts 2.0的提议
- 作为Struts的子项目
- 于Struts类之间没有直接的联系
- 作为JSF技术的扩展:“JSF 1.0 并没有保护所有的我们需要的东西,所以我们加入目前需求的。所以Shale增加了比如说客户端校验,Ajax,等…作为JSF 2.0的铺路石。期间,Shale 作为证明的基础。”
- Shale的特性
- Web流
- <city w:st="on"></city> <place w:st="on"></place> Ajax
- Spring和Tiles的集成
- 客户端和服务端的校验
- 类似于Tapestry的展示层的参数化的子树
- 工具:Back-Button的滥用,文件上载,JNDI API
- Web流
- Shale的扩展点
- ShalePropertyResolver
- ShaleVariableResolver
- DialogNavigationHandler
- ShaleViewHandler
- TilesViewHandler
- ShalePropertyResolver
- “如果不知道JSF本身,JSF是非常非常易扩展的”
Tapestry
- 核心价值:
- 简化-Web应用不能像火箭科技!
- 一致性-为页面工作就是为组件工作,为小应用工作就是为大应用工作,不同的开发人员对于相似的问题应该有相似的解决方法
- 高效性-应用软件应该是高性能和易扩展
- 反馈-如果有什么地方出现问题了,本框架不会中断,事实上,它会提供一些有用的诊断
- 简化-Web应用不能像火箭科技!
- 工具:
- 不需要使用工具
- 可以使用你已经使用的工具.
- 不需要使用工具
- 在Tapestry 4.0中的新特性(子集):
- 支持注解
- 真正优秀的集成能力
- 管理服务端状态具有更大的弹性,非常高效的获取什么在事务的明细.
- 支持门户
- 支持注解
- Extensibility可扩展性:
- Over 180 extension points 超过180个扩展点
- Built around Component Object Model with many layers 在需要层上集成了组件对象模型
- Terrific ability to override, change, and customize过载,更改和客户化的强大能力
- Great support for component libraries which are open source and available.支持开源和可用组件库
- Over 180 extension points 超过180个扩展点
- “对于其他的框架来说,Tapestry是被追赶者!”
Wicket
- 还是一个新生家伙.
- “Wicket是容易的,优雅的,并且是强有力的”
- 易用:
- 简化,一致,明显
- 重用组件
- 非插入的
- 安全
- 效率/可扩展
- 简化,一致,明显
值得注意的引用:
- “谁都知道JSF优于Struts,当然,JSF和Tapestry不相上下”
- “Struts是一所老学校,所以恢复它”
- “如果你需要一个像这样的工具,那么你的扩家可能太复杂了”
- “你可以说,但是不能让人们去用它”
- “如果你要节省你的Struts代码,JSF可以做到”
- “在事实你可以采用标准的方法去扩展框架,从而达到在某个功能点构建你的扩展,但是事实你不会真在Struts和Webwork上真的这样去做”。有的人说你不需要使用一种想象的事件模型去获得Web应用的重用。
我们的积分卡
TSS尽量用分数来记录决斗,我们对每个框架在两个领域以5分总分作为记录:
- 技术特性
- 商业使用
技术特性
| ||
框架
| 分数
| 原因
|
JavaServer Faces (JSF)
| 4.8
| JSF赢得大部分分是因为它是第一个真正支持Web组件的。我们的分析师感觉JSF在简单和优雅方面缺乏指控是不当的。JSF是易用的,强大的,并且是革命的。已经存在的Shale和Spring表明JSF的确是可扩展的。
|
Webwork
| 4.2
| Webwork的多层MVC作为先驱是革命性的,然而我们感觉Webwork的HMVC和模板机制于JSF比已经黯然失色,其思想已经融入了JSF中。
|
Shale
| 4.95
| 如果说Shale站的比其他框架高,那是因为它站在巨人的肩膀上。通过扩展JSF,包含了Web流,支持Ajax,集成tiles,客户端检验,我们的感觉是Shale展示了Web框架的需求和机会的未来。
|
Tapestry
| 4.75
| Tapestry是Web组件的先锋,在讨论中谈到的“JSF和Tapestry不相上下”本非遥远。然而,JSF的标准扩展点,和第一个支持门户的开发对于Tapestry来说是强有力的竞争优势。我们看比赛已经结束,当然我们乐意看到Tapestry支持JSF的标准接口和支持交互性。…明确的说,我们喜欢能够用Tapestry写JSF组件,用JSF组件的方法去用Tapestry组件。我们热切的期待下一次比赛
|
|