WEB开发网
开发学院WEB开发Jsp Java Web 框架的"甜点" 阅读

Java Web 框架的"甜点"

 2008-01-05 10:16:11 来源:WEB开发网   
核心提示: 这是一篇很有趣的文档,所以摘要一下,Java Web 框架的"甜点",其实类似阅读笔记,似乎是3/25发布的:不知怎么翻译Sweet Spots,但不是对它的移植,6、你对Ruby on Rails的看法如何?我认为我们有很多需要从RoR学习的地方,难道翻译为甜处

这是一篇很有趣的文档,所以摘要一下,其实类似阅读笔记,似乎是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等。

2、它不适合于什么样的场景?在这些场景你推荐什么fremework?它是哪个?
Spring MVC:不适合需要组件化开发的场景。它是一个request驱动的MVC。那些场景推荐JSF或Tapestry。
Spring Web Flow:处理线性页面流,不适合一般的"自由浏览"。当然Spring Web Flow可以与request驱动或者组件驱动共存。

3、在下面提到的framework中,你试验过他们么?假如试验过,你比较喜欢哪个?你不喜欢哪个?
Spring框架支持Struts和JSF集成。

4、你的framework的未来会怎样?对于用户开发会有什么方便使用的变化?你会原生支持Ajax么?你们计划支持它了么?
Spring MVC:简化jsp标签。更多的MVC配置schema。CoC风格的默认控制器、URL影射、view,学习Rails和Stripes的优点。增强数据绑定和验证(支持范型绑定)。Portlet支持。Spring也要接受Ajax,使用DWR库。
Spring Web Flow:一大堆,关心的可以自己看......

5、有对你们的framework的传言需要澄清么?假如有,是哪个?
Spring MVC难于配置。在Spring 2.0,将会改善,可以使用自己定义的基于schema的配置。

6、你对Ruby on Rails的看法如何?
Spring MVC:RoR非常有趣。不过现在就拿出来用还有点幼稚。这里举了个例子,关于变量的复数形式的处理,RoR会使用这样的CoC风格来处理变量list,而Spring MVC也实验了种种风格,但是受到的结果却很差。人们认为英语的复数很古怪,没有一定的规则,所以会带来混乱,如(person -> people)。所以Spring ...

Stripes(Tim Fennell)

1、你认为你的framework的“甜点”在哪里?他最适合哪种类型的项目?
与Spring MVC、WebWork等相同。它提供高质量action驱动的框架的同时,尽量简化配置,增进开发效率。Stripes适合复杂的数据交互的场合。这种情况下绑定验证的强项就完全体现出来了,能够很好的处理form和map转换等。

2、它不适合于什么样的场景?在这些场景你推荐什么fremework?它是哪个?
所有的action驱动的framework都适合用户在非Ajax驱动的情况下在一个页面进行松关联(loosely
related)和无状态交互的情况。适合每次都刷新的页面。治理多窗口间持续状态的应用会比较麻烦,此时应该选择JSF。不过我认为90%以上的Web程序都是前者,JSF只适合剩下的那9%,AJAX对于治理无状态UI更加适合。客户端不需要AJAX,则可以看看Wicket,它更加简单。

3、在下面提到的framework中,你试验过他们么?假如试验过,你比较喜欢哪个?你不喜欢哪个?
用过Struts、WebWork、Spring MVC。其中Struts做过商业项目,不过这个东西带来的麻烦远比带来的效率提升要多。它认为这些MVC都有三个缺点:暴露了过多的复杂性给可发者。没有提供足够的开发便利性,没有提供足够多的错误和提示信息,也没有date格式化等小的便利(其实有)。稳当太差。

4、你的framework的未来会怎样?对于用户开发会有什么方便使用的变化?你会原生支持Ajax么?你们计划支持它了么?
1.3要加入Inteceptor,实现AOP功能。验证系统要加强。支持Ajax。我还在寻找一个好的Ajax/Javascript库。

5、有对你们的framework的传言需要澄清么?假如有,是哪个?
这些观点:1、Stripes使用了annotation代替XML,只是换汤不换药:由于元数据更接近代码,所以修改默认的配置非常方便,不像XML那样复杂,这是实质的变化。2、Annotation意味着你只能有一套配置:我认为90%的action都有自己的一套配置!Stripes会根据继续关系寻找Annotations,子类的annotation会覆盖父类的,因为像validation都是可以继续的,假如非凡需要还可以覆盖。这样很合理。在1.3中答应validations基于UI事件进行。它向后兼容,不需要可以不用。

6、你对Ruby on Rails的看法如何?
我认为Java社区有很多可以从RoR学习的地方。Stripes学习了RoR的前端部分,开发者可以减少配置量。但是RoR的RHTML让我想到了以前的JSP中混乱的scriptlet。而后面的ActiveRecord是一个很好的理念,实现的也很好。ActiveRecord比Hibernate等复杂的ORM工具要轻易理解,因为这样的特点RoR才引起了这么大的波澜。

Struts Action 1(Don Brown)

1、你认为你的framework的“甜点”在哪里?他最适合哪种类型的项目?
文档和用户基础,书籍和背后的支持。轻易雇到人(也轻易找工作)。虽然其他项目的理念比这个要先进,但是这些不算什么。实际上,Web层是很轻易也很直接的。

2、它不适合于什么样的场景?在这些场景你推荐什么fremework?它是哪个?
假如你需要portlets或者复杂的页面(显示很多东西),那么Struts要么无法工作要么太枯燥。这种情况你需要一个基于组件的framework,如JSF、Tapestry/Wicket。

3、在下面提到的framework中,你试验过他们么?假如试验过,你比较喜欢哪个?你不喜欢哪个?
这些我基本都试验过,他们每个都工作的很不错。

4、你的framework的未来会怎样?对于用户开发会有什么方便使用的变化?你会原生支持Ajax么?你们计划支持它了么?
Struts Action2基于WebWork2,很快会开始。现在已经支持Ajax了,我们在寻找更加轻易的开发方式,JSF支持(Struts Shale),continuation支持,还有支持更多的脚本语言(BSF扩展脚本撰写Action)。

5、有对你们的framework的传言需要澄清么?假如有,是哪个?
Struts太过时了,而且也不酷,难于使用。但是你可以自己修改或者扩展它。我认为团队对于你的限制远大于framework对你的限制。

6、你对Ruby on Rails的看法如何?
不需要D&D工具,旨在帮助开发人员提高开发效率的好例子。我们在Action2中将学习它的先进理念。

Tapestry(Howard Lewis Ship)

1、你认为你的framework的“甜点”在哪里?他最适合哪种类型的项目?
我想Tapestry对于中等规模或者大规模的应用会带来很多好处(甚至你可以在单页面的应用程序中获得好处)。这里有答应你创建新的组件的良好工具。Tapestry不关心数据从哪里来,很多“项目类型”都基于切面(aspect)(如CRUD vs. rss feed vs. etc.)。我认为Tapestry非常轻易与IoC集成(HiveMind或与Spring),方便进行测试。

2、它不适合于什么样的场景?在这些场景你推荐什么fremework?它是哪个?
我在其它Java framework中没有找到到强于Tapestry的优点。但是对于RoR,我自己没有使用过使用,很难说RoR中的项目应该是什么样子。我没有仔细对比过RIFE,它看起来受了RoR影响,尤其是类似ActiveRecord的数据访问层。但是假如你的应用需要特定的URL格式,那么在Tapestry中奋战胜算不大。

3、在下面提到的framework中,你试验过他们么?假如试验过,你比较喜欢哪个?你不喜欢哪个?
在这两年来我没怎么尝试过Tapestry以外的东西。我没怎么学习RoR,因为时间太有限了。

4、你的framework的未来会怎样?对于用户开发会有什么方便使用的变化?你会原生支持Ajax么?你们计划支持它了么?
Tapestry 4.0有很好的Ajax支持,通过Tacos库。而Tapestry4.1还要进一步强化这方面的支持。
Tapestry 5.0提供了明显的改进:没有abstract类(Tapestry的怪癖:)。没有强迫的继续关系。对属性进行annotation而不是方法。没有XML,只有模版和annotaions。只能类装载,自动寻找类的变化。最小化API,超越annotaion。面向方面(Aspect-oriented)模块构造,使用mix-ins。

5、有对你们的framework的传言需要澄清么?假如有,是哪个?
Tapestry3.0还不轻易测试,4.0改善了一些。Tapestry只是个人秀;实际上我们有很多活跃的贡献者。Tapestry的学习曲线非场陡峭。它只有漂亮的模版实现;实际上Tapestry的特点在于状态治理(答应对象存储状态,而不是多线程的单例来治理requests之间的游离和持久状态)

6、你对Ruby on Rails的看法如何?
很有影响力。但是模版的实现非常丑陋。我听到了很多意见,关于RoR的优缺点。基于我的基本理解,这些观念对Tapestry4产生了影响(它对Tapestry 5影响更深)。
RoR意味着限制了你的选择:假如你选择RoR那么就要尊旬它的实践(CoC..),看起来你的钱会花的恨值。这些类似Microsoft的哲学。而Java更崇尚给你更宽松的选择,不限定你使用的工具,但是暧昧的说这需要你对你的工具理解更深。不仅对Tapestry,还对于JEE、Spring这写entire stack的框架,需要从RoR学习,不仅提供工具,还需要提供整套的解决方案。

Trails(Chris Nelson)

1、你认为你的framework的“甜点”在哪里?他最适合哪种类型的项目?
Trails的应用程序只需要Web界面和持久化的domain model就可以了。Trails给你的domain
model快速的提供一个界面,除了POJO自己不需要附加的代码。Trails答应你修改界面的外观和行为,包括验证、i18n、安全。这些都不需要java代码生成,不喜欢代码生成的人应该感觉很舒适。

2、它不适合于什么样的场景?在这些场景你推荐什么fremework?它是哪个?
Trails讲究够用就好。它答应你快速交付,问问你的客户:“这样够好么?”。这会改变你的工作流程,当然这不是可以覆盖所有需求的解决方案。当UI需求很高,Trails没有优势。我认为Trails适合于混合的应用,对于治理员他们只需要够用就好,那么就可以使用Trails。其它的部分我们可以订制开发,我们在使用Tapestry、Hibernate、Spring来实现这些部分,Trails正是基于它们。对于非交互的应用,Trails也不适合,如报表应用,可以考虑Eclipse BIRT。

3、在下面提到的framework中,你试验过他们么?假如试验过,你比较喜欢哪个?你不喜欢哪个?
我用Struts很多。它曾经是伟大的framework。主要的缺陷是它不能自动帮定数据到domain model。我也研究过JSF,它比Struts强,但是自定义组建非常难。Tapestry非常便于自定义组建,尤其对于建立高阶组件(有其它组件组成的)非常方便,Trails正在使用它。

4、你的framework的未来会怎样?对于用户开发会有什么方便使用的变化?你会原生支持Ajax么?你们计划支持它了么?
对于Trails来说我们站在巨人的肩膀上。Tapestry在ajax功能作了很多努力,所以Trails也不难与其共舞。但是我们需要创建更多的例子来演示这些。我们也致力于让Trails轻易介入到已经进行的项目中。以后Trails还要加入基于实例的安全(instance-based security)(目前正在使用基于角色的role-based),还有method invocation。

5、有对你们的framework的传言需要澄清么?假如有,是哪个?
Trails是对RoR的移植。Trails的名字来自Rails。它是基于Rails的理念,但不是对它的移植。

6、你对Ruby on Rails的看法如何?
我认为我们有很多需要从RoR学习的地方,那将帮助我们享受开发Web程序的舒服。

Tags:Java Web 框架

编辑录入:爽爽 [复制链接] [打 印]
赞助商链接