运用Ruby纤程进行异步I/O:NeverBlock和Revactor
Ruby 1.9的纤程(Fibers)和非阻塞I/O越来越收到关注了。我们对来自NeverBlock项目的Mohammad A. Ali和来自Revactor项目的Tone Arcieri进行了访谈。
作者 Geoffrey Wiseman译者 Jason Lai 发布于 2007年7月11日 下午8时30分
Grails开发团队成员Marc Palmer发表了一篇博客文章,针对开发人员对Grails常见的一些误解逐一进行了说明。例如针对“对于我来说,Grails还不够成熟”,他这样回应:
针对这个误解,我想不断增长的商业网站数量就是最好的答案了。同时,Grails也是基于HIbernate、Spring和SiteMesh这些成熟完善的框架构建的,更不用说作为万年常青树的Java JDK了。Groovy项目都已经有超过三年的历史了。
接着,对于“Grails使用的是一门解释型语言(Groovy)”这个误解,他谈到:
Groovy在运行时自动编译成Java虚拟机字节码,它绝绝对对彻彻底底不是一门解释型语言。句号。绝不。我说了绝不了么?一点儿也没错。
最后,讨论到Grails是否支持Rails的一个克隆产物,他如是回答:
Ruby on Rails引入了不少非常好的主意,并将它们合为一体。Grails将其中的一部分应用到了Groovy/Java的世界中,但加入了许多Ruby中并不存在的特性和概念,所有这些东西都是以一种对Groovy和Java程序员有意义的方式展现给他们的。
Graeme Rocher顺势而上,也提出了自己的Grails误解和问题列表,比如说“在我们有了JRuby on Rails之后,谁还要Grails呢?”:
这个问题很有代表性,也是对“Grails到底是什么”最大的误解之一的根本所在。JRuby on Rails是让Rails运行在像GlassFish这样的Java EE容器上非常优秀的方式之一,就是这样而已。但Grails的目标却大为迥异,它并不是Rails在Groovy语言上的一个移植版本,而是将业界内最为强悍的组件(比如说Spring、Hibernate、Quartz、Compass和SiteMesh等)以最佳方式组合起来的一个实践,并通过采纳无配置规约(Convention-over-Configuration,CoC)使它们符合“不重复(Don't Repeat Yourself,DRY)”原则。
我们并不是在重造轮子,而且由于Grails内核的绝大部分都是以Java编写的,它也显得更加强壮和稳定。事实上,从内核角度看Grails是一个Spring MVC应用,可以被部署到所有的主流容器之上,不仅仅只有Glasshfish,还有大型商业容器,比如说WebLogic、WebSphere和Oracle AS。
再有,“为什么Grails比Rails更适用于企业应用?”:
原因很多,最显著的两个原因就是Spring和Hibernate。到目前为止,有不计其数的组织在采用Spring和HIbernate,他们都有既有的Spring上下文环境,以及已经构造好的Hibernate领域对象等。
在我开始参与Grails项目之前,我就经历过同样的情况。我们设计Grails的目的就是为了让它和这些框架尽可能无缝地整合起来。因此,我们打个比方,你可以把一个用Java编写的Hibernate领域模型及其对应的配置文件直接扔进Grails应用中,然后就可以使用动态的查询方法,并且直接使用GORM了。
此外,Grails控制器使用了标准的Servlet API对象(如request、response和session等),因此可以和其它的Servlet一起使用。毕竟,掀起它的盖头之后,我们会发现它不过是一个Spring MVC应用。另一方面,Rails几乎是按照和EJB2一样的方式设计的(在我发现这点时,怎一个“震惊”二字了得!)。也就是说,你在扩展ActiveController和ActiveRecord等框架对象时,你也就被绑定在了这套框架上。
在Rails里面根本就不存在领域模型的说法,Rails的模型就是数据库表。这当然是一件好事了,但在企业内部,同一个领域模型可能会在许多不同的应用中服用,比如说桌面应用和Web应用。在Java里,这实际上是非常成熟完善的,通过把类对象及相应映射文件打包成一个JAR文件即可。
亲爱的读者,关于Grails,您还存在什么问题吗?或者您还见过对Grails用途的其它误解么?请在InfoQ的Java社区与我们一同分享吧。
查看英文原文:Grails Misconceptions
Rails几乎是按照和EJB2一样的方式设计的(在我发现这点时,怎一个“震惊”二字了得!) 看到这句话,我也相当震惊
确实得说 Rails 的框架耦合度确实太高了,这也是 DHH 的个性所致吧。 Java世界里面强调的就是解耦以便切换其它可能解决方案,文化使然。
在ROR里面我们出来用那个该死的模板,我们有别的选择吗?我们如果想不用ORM我们有选择吗?我们如果想换一个缓存我们有选择吗?我们如果想换一种开发方式(不按照ROR既定的)有选择吗? 答案是没有。
Grails在国外已经比较有活力了,在中国我不清楚这样,可是见到这么快就有人翻译了,有人来关注,可喜可贺。
楼上的朋友如果对 Grails 感兴趣,可以上我们的主站看看,我们有一本书,叫做 Getting Started with Grails,可以免费下载的。 另外,这本书的中文版,我们也有了 SpringSide 团队的倾情翻译,会在近期内在 InfoQ 中文站上推出,敬请关注!
Getting Started with Grails 这本书貌似有些老了 现在GRails已经0.5.6了 里面有大部分内容都更新了
虽然老了点,但是基本步骤都是一样的。除了一些api、tag的改动,还是有参考价值的,呵呵。 我正在翻译那篇grails的文章,版本更老。但是还是说了些那本mini book中一些没有提到的东西,都可看看,快翻译完了。
不知道你想选择什么呢?你知道CoC就是最佳实践的总结,就是告诉你应该怎么做。因为Ruby不是Java。 你看看Python界里面的TurboGear和Django了么?TurboGear号称各层都可以替换,但是现在已经濒临死亡。而Django却因为足够鲜明的个性继续保持告诉发展。 RoR的模版引擎本身可以替换,也不是该死的,实际上很好用。
Rails是简单还是复杂
Ruby 1.9的纤程(Fibers)和非阻塞I/O越来越收到关注了。我们对来自NeverBlock项目的Mohammad A. Ali和来自Revactor项目的Tone Arcieri进行了访谈。
InfoQ中文站有幸与Google中国的产品经理杨巍先生在一起探讨了OpenSocial的相关话题,包括OpenSocial的初衷、构成要素、实现方式、以及要实现它的技术储备等等。
Ryan Cooper对Amr Elssamadisy的新书发表了评价,并认为书中提供了一种为实施敏捷量身定做的框架。本书并没有给出一种人人可用的敏捷方法,而是为读者提供一些模式和工具,用以找出哪些敏捷实践可以最有效地达到该组织机构的特定目标。
这个由业界主要专家们参加的座谈会探究了在使应用程序具备尽可能好的伸缩性及性能的过程中所面临的挑战和思考过程。
本视频主要对OpenSocial进行了分析,并对实现的方式进行了介绍。其中包括:OpenSocial的开发经验、Container Provider的技术准备、平台的构成要素、具体的规范、以及对未来的展望。
Memcached在大型网站被应用得越来越广泛,但是Java客户端并不多,本文作者基于现有的开源客户端进行了封装优化,并翔实记录了这一过程。
在他们文章的第二部分,作者探讨了动态业务应用的架构并介绍了资源容器的概念。他们示范了如何在JEE之上构建这个架构,以及它如何影响实现生产力。
ClickOnce让WinForms应用程序的部署轻而易举。David Cooksey演示了如何在ASP.NET中编写一个HttpHandler来实现对ClickOnce部署的版本细分。
9 条回复
回复