Java Web 框架的“甜点”

发表于:2007-06-22来源:作者:点击数: 标签:
下一页 1 2 这是一篇很有趣的文档,所以摘要一下,其实类似阅读笔记,好像是3/25发布的: 不知怎么翻译Sweet Spots,难道翻译为甜处、甜头、蜜点、蜜穴? 本文基于对以下人的采访(最后两位的看法独到还是自己看吧!): JSF Jacob Hookom RIFE Geert Bevin

下一页 1 2 

   

这是一篇很有趣的文档,所以摘要一下,其实类似阅读笔记,好像是3/25发布的:
不知怎么翻译Sweet Spots,难道翻译为甜处、甜头、蜜点、蜜穴?

本文基于对以下人的采访(最后两位的看法独到还是自己看吧!):
JSF Jacob Hookom

RIFE Geert Bevin
Seam Gavin King
Spring MVC Rob Harrop
Spring Web Flow Rob Harrop and Keith Donald
Stripes Tim Fennell
Struts Action 1 Don Brown
Tapestry Howard Lewis Ship
Trails Chris Nelson
WebWork Patrick Lightbody
Wicket Eelco Hillenius


JSF(Jacob Hookom)

1、你认为你的framework的"甜点"在哪里?他最适合哪种类型的项目?
当你希望浏览器程序像桌面程序一样工作的时候,你可以遵循标准并获得大量第三方支持。它致力于降低复杂度。它允许你不与view和特定的action、参数传递、状态传递、渲染打交道就可以进行高质量开发,不管是否使用工具。

2、它不适合于什么样的场景?在这些场景你推荐什么fremework?它是哪个?
它不适合大规模的、只读(其实指读为主)的网站。在这种情况推荐Struts,因为知识库丰富(应该指文档和用户群)。

3、在下面提到的framework中,你试验过他们么?如果试验过,你比较喜欢哪个?你不喜欢哪个?
Seam:
优点:非常简单直接
缺点:对于大项目过于简单;没有模块化开发的好例子
Struts:
优点:巨大的文档和用户群;跟着它没错
缺点:状态/行为的分离过于教条化
WebWork:
优点:比Struts易于使用
缺点:复杂的UI难于维护,UI代码过于复杂(JSF作者对action
Framework都攻击这一点)
Tapestry:
优点:概念新颖;可以应付复杂的UI
缺点:对于一个组件化(JSF主要竞争对手),它依然依附于page/action的概念

4、你的framework的未来会怎样?对于用户开发会有什么方便使用的变化?你会原生支持Ajax么?你们计划支持它了么?
他认为JSF这个标准下这些应该有第三方提供。JSF(2.0)会提供"Partial Faces Request",它是Ajax实现。JSF也会增强annotation组建编程。

5、有对你们的framework的传言需要澄清么?如果有,是哪个?很多JSF书都拿Struts作为对比。他认为这不能体现JSF的特点。他认为Struts和WebWork能做到的JSF也能做到。

6、你对Ruby on Rails的看法如何?
它与WebWork一样好用,它的CoC(Convention over Configration)和脚手架非常好用。他认为CoC可以被应用在任何framework,他认为这是RoR最大的优点。他还认为RoR会走上其它framework的路(复杂性),因为人们需要自己的扩展。

RIFE(Geert Bevin)

1、你认为你的framework的"甜点"在哪里?他最适合哪种类型的项目?
你可以付出10%的工作量,得到其它framework的90%的......,它是一个full-stack framework(如RoR)。它吸收了成熟的分层框架的架构,并将共同的优点汇集在一起。提供了web continuation,POJO驱动的CRUD生成,可扩展的基于组建的架构,无session的状态控制,关注REST作为API,双向无逻辑模版引擎,集成了内容控制框架(CMS?)。每个层次的组建提供了可复用性(AOP,site,sub-site,page,widget,portlet等)。适合于团队快速开发公共Web项目,适合喜欢开发可复用组件的人。

2、它不适合于什么样的场景?在这些场景你推荐什么fremework?它是哪个?
团队中的每个人都有其它framework的知识,难于培训他们。开发状态相关的服务器端Web组件,而不是用RIA或Ajax去实现。第三方支持很重要的情况下(可怜RIFE用户群还不大)。他推荐这种情况下使用JSF。或者在XML为主要发布形式的情况下,推荐Cocoon。

3、在下面提到的framework中,你试验过他们么?如果试验过,你比较喜欢哪个?你不喜欢哪个?
他试验过WebWork,JSF,Wicket。他喜欢WebWork的简单,但是不喜欢它的模版方式(tag的template,应该),它也不提供组件封装。他认为JSF的工具支持非常吸引人。Wicket的纯Java实现很不错,可惜XML配置很不爽。

4、你的framework的未来会怎样?对于用户开发会有什么方便使用的变化?你会原生支持Ajax么?你们计划支持它了么?
关于Ajax,RIFE刚刚集成了DWR,而且选定以后也使用这个。集成Dojo,Scriptaculous,Prototype都很容易集成进来。

5、有对你们的framework的传言需要澄清么?如果有,是哪个?这些错误理念:
1)、RIFE的XML配置繁琐
2)、RIFE是continuations server
3)、RIFE重新造轮子没有提供新鲜东西
4)、RIFE的模版语法很蹩脚过于简单和业余
5)、RIFE是基于request的framework
6)、RIFE的功能太多,学习曲线陡峭

6、你对Ruby on Rails的看法如何?
RoR对Java社区的冲击非常棒,元编成也得到了信任。RoR没什么特殊之处,也没有从Ruby语言获益很多。
我讨厌:它的模版。Partials(RoR中的组件)。URL的分散处理。Active Record提供了从数据库schema而来的DSL,但是却不是从domain model而来。没有l10n和i18n支持。手动状态转换。不能在JVM运行(......)。实际上脚手架生成了实际代码。Ruby缺少工具和IDE。

Seam(Gavin King)

1、你认为你的framework的"甜点"在哪里?他最适合哪种类型的项目?
拥有丰富用户交互体验的应用。方便实现多窗口的操作,回退的支持,单窗口多工作区,无状态浏览。对商务流程(BPM)的集成是独一无二的。Seam方便使用数据驱动的ORM。遵循JSF和EJB3,多任务支持(多窗口/多工作区),BPM的领先解决方案

2、它不适合于什么样的场景?在这些场景你推荐什么fremework?它是哪个?
不适合只是将数据从数据库显示到网页的应用,这时应该使用PHP或RoR。不适合需要设计特别的HTML组件的情况,此时应该选用Tapestry或Wicket。还在使用JDK1.4的人们。还有那些喜欢Struts的人(嘿嘿,够狠)。

3、在下面提到的framework中,你试验过他们么?如果试验过,你比较喜欢哪个?你不喜欢哪个?
JSF:喜欢他的事件/交互模型。喜欢他的EL和模型绑定。不喜欢那么多XML(为什么没有annotation)。创建自己的controls太难了。
Tapestry:非常好。form验证是它的杀手锏!模版方式很有创意。不过非基于POJO的组件模型则让我对它失去兴趣。
RIFE:这个东西很怪,但是有创业也有趣。我想进一步学习。如果学习先要自费武功:D
Struts:这个东西的模型view绑定太复杂了。东西已经过时了。
WebWork:比Struts好一点,不过也过时了。XWork曾经是个很好的实现,不过现在也过时了。

4、你的framework的未来会怎样?对于用户开发会有什么方便使用的变化?你会原生支持Ajax么?你们计划支持它了么?
Portal支持。远程框架Seam Remoting Framework(Ajax)。模版消息的工具支持。以后还要集成ESB,计划引擎和异步支持。

5、有对你们的framework的传言需要澄清么?如果有,是哪个?
这些都不是真的:JSF不能处理GET requests。JSF post后无法redirect。JSF不能与REST共存。

6、你对Ruby on Rails的看法如何?
它是PHP的很好替代品。如果它有一个正经一点的持久化层它就可以和Java竞争了。

Spring MVC(Rob Harrop)和Spring Web Flow(Rob Harrop and Keith Donald)

1、你认为你的framework的"甜点"在哪里?他最适合哪种类型的项目?
Spring MVC:
稳定可扩展,支持了i18n、文件上传、异常处理,这些稳定的支持给开发者坚实的工作基础。是最佳实践,告诉你怎么做是最好的。与Spring集成,领先的IoC远生支持。支持,Spring社区活跃和庞大。Struts开发者可以平滑过渡。适合多种项目,可选的多种result类型。
Spring Web Flow:内置任务处理引擎,支持线性处理过程中的持续状态。抽象,减少开发的关注点。适合多种项目类型,插件支持Spring MVC、Struts、JSF等。

原文转自:http://www.ltesting.net