Grails 1.0发布：增加ORM DSL、Filters、REST等特性

作者 Geoffrey Wiseman译者 李剑 发布于 2008年2月25日 上午4时38分

社区

Java

主题

Web框架

标签

Groovy,

Grails

Grails 1.0已经发布了。这个消息在项目邮件列表、Graeme Rocher的博客和Grails.org都进行了声明。InfoQ对Grails项目领导人、G2One的CTO兼共同创始人Graeme Rocher进行了采访，针对Grails 1.0发布中包含的种种特性，此版本的成熟度、易用性及Grails的未来计划进行了深入交流。

Grails 1.0的发布说明页面上列出了所有新特性的细节，其中包括：

• ORM DSL，在与历史遗留的数据表打交道时，可以避免依赖Hibernate映射。
• 易于使用的Filters，它可以被应用于特定的actions、一个完整的控制器或是贯穿基于URI的多个控制器。
• 支持构建REST服务。
• 内容协商支持，用它可以便于在HTML、XML、JSON和其他内容表示形式之间切换。
• 自动化XML/JSON Unmarshalling，用于支持通过XML或是JSON来提交数据。这项功能对于Web Services或是RESTful方式很重要。
• 范围内服务，允许在服务中存储状态时使用多种语言模型。

Grails还利用了Groovy 1.5中的一些特性，如注解：

在1.0中，你可以使用与GORM对立的JPA风格的注解（目前只支持用Hibernate作映射），如果你喜欢的话。你还可以使用所有Spring的注解，如<tx:annotation-driven>。

虽然对于一个已经有过很多次发布的软件项目而言，1.0版不过是又一次发布而已，但它依然可以给项目团队以强大的精神鼓舞和自信心的强化。如Marc Palmer所说：

很多人都能理解，1.0版对于心理作用来讲是非常重要的。它为将来的发展设定了基线，夯实了基础。Grails 1.0有着令人难以置信的庞大的核心功能集，而且它的免费插件数量也在与日俱增，这些插件为Grails添加了各种各样的强大功能。

当问到Grails的成熟度是否处于“就绪情况”时，Graeme Rocher回答说：

我可以很自信地说，它已经足够[成熟/就绪]了！不过严格说来，从来没有任何一款软件能够做到在发布以后不出现bug，如果一个软件厂商说他们的软件没有bug，那他肯定是在撒谎。我能说的就是，如果我们过去所做的事情是在将Grails向正确的方向推进的话，那它在这条路上已经走了将近三年之久。我们很有信心，如果人们试着用了Grails，那他们就会喜欢上它。

Graeme列举了一些Grails的成功案例，他从网站上列举的那些开始讲起，后来又补充说：

Grails的主要应用已经渗透到了企业内部，要把它们挑出来或是直接进行讨论还多少有点困难。比如Grails已经在法国一些主要的广播公司中得到了应用，还有一家大型US托管提供商和伦敦排名首位的几家HR公司。另外，SAP也有了Composition on Grails项目，它可以用来在SAM NetWeaver 7.1上面快速构建组合应用。

Grails的基础是一个成熟的栈，从Groovy语言（前不久，它已经为向企业应用进军最好了准备）到Spring和Hibernate。Graema补充说：“你会把Spring和Hibernate看作风险吗？”

Graeme谈到了为什么Grails会被当作企业应用中的优秀选择：

对于那些现有架构常常是基于Spring和Hibernate构建的大型企业来说，掌握Grails特别简单。

往底层来说还有很多理由，譬如说，要重用现有的Spring bean定义再简单不过了，你把必要的XML文件扔进去就行了（在Grails里，这可能是你唯一需要看一眼XML的地方！）。

你还可以重用Hibernate的领域模型，同时还能享受Grails的所有好处，这个就不值一提了。

他接下来谈到了开发团队可以很轻松地使用Grails加速开发的步伐：

因为Groovy的设计思想是，从底部起力求做到在语法层面上尽可能地与Java平滑集成，所以一个由Java开发人员组成的团队肯定很容易把速度赶上来。

Grails本身也是对Java EE大幅度的简化，因为说句实话，大多数现有的Java框架都比他们本来应有的样子复杂得多。这种巨大的复杂度差异也使得软件工程师们很难从其他平台转换到Java平台上来工作。

从这一点来看，Grails也为其他社区的开发人员——如PHP——打开了一扇通往Java世界的大门。

不过，能够轻松自如地采用一整套的Java栈也会偶尔带来些代价：

在种种危险中，最主要的一点是我们已经对底层框架的抽象太成功了，以至于有时会出现问题。

例如，如果你不理解Hibernate中延迟加载和主动抓取之间的区别，那你肯定就会遇到麻烦。不过这些危险和其他任何Java项目并无不同，只是新手很容易会不时落入这些困境中。

有些人认为用动态语言做原始的开发很容易，但是维护成本特别高，因为没有比较有效的工具支持。Graeme反驳说：

我相信Groovy是很不一样的。首先，Groovy不是动态型别，而是任意型别。这就说明你可以指定它的型别，也可以不指定。在大多数情况下它的型别都是可以被推断出来的。譬如说，用了IntelliJ的JetGroovy插件，或是其他类似的工具，你就可以像Java语言一样获得对Groovy完整的重构和代码分析支持。

而且，Groovy还是一个拥有联合编译器（joint compiler）的真正的混合源码（mixed source）语言，从Java转换到Groovy和转回来都一样容易。我觉得，其他动态语言的使用者会失去Java的代码分析和重构的能力，但Groovy绝不在其中，所以它的维护不像其他动态语言一样，和Java有那么大差别。

我希望以后Eclipse和Netbeans对Groovy的支持可以达到IntelliJ的水准，让更多的开发人员都可以接触到这种开发类型。

在展望Grails的未来时，Graeme谈到了1.0以后其他版本的发布计划。他从Groovy 1.6和性能说起：

1.0为向后的兼容性设定了一个基准。从现在开始，不管添加什么新特性进来，我们都要把现有的应用等相关情况牢牢放在心上。

肯定会有几个1.0.x版本，不过对于1.1而言，还有很多事情需要重点解决。首先，Groovy和Grails的路线图关联的十分紧密，所以Groovy 1.6中将要添加进来的一个重要内容也会被加入Grails 1.1中，那就是通过调用点缓存技术（call site caching techniques）带来的性能方面的巨大提升。

我们的目标是让Groovy可以和JVM上其他一些最快的动态语言建立内联，这样做对Grails只会有好处。由于它是建立在坚实的基础之上，已经受益良多了。对于Grails自身而言，日程表上最重要的事情就是和Java EE技术及项目进行进一步的集成。

Marc Palmer也提到了一种使用真实项目的新型集成测试将会被应用于Grails 1.0和之后的版本中：

我们也已经把一个用于自动运行功能性Web测试的框架放到了SVN的“specimen”应用中，它将会成为Grails持续集成构建的一部分。在服务器环境方面会有一些暂时性的困难，但是整个过程都是在本地执行的，我们只需要向SVN中放入一些优秀的测试应用，更重要的是，在应用中加入一些全面的Web测试脚本。

这将会很成功地构建出Grails的一个“TCK”，根据1.0版的基线功能保证其稳定性——另外，Grails一直向产品内部不断地加入单元测试代码，目前的单元测试数量已经十分庞大了，这也是持续集成构建平台的一部分（Bamboo也实在是太棒了）。我们也非常欢迎人们贡献非试用性的应用程序和全面的单元测试、Web测试。

Grails 会继续集成Java领域内的最新技术，为做到一栈式的集成，成为Java世界中顶尖的框架之一而努力：

在1.x版本中，我们计划加入对JPA、JSP标签库和Portlet的支持，通过插件提供与其他一些流行框架的集成，像JSF、GWT、Wicket和Struts等。另外，我们计划通过一个Maven 2插件把Grails放入Maven的生命周期中，从而随着Grails提供对Maven 2的开箱即用（out of the box）的集成。记住，Grails不仅仅是一个框架，还是一个软件栈，它的目标是解决软件生命周期内的所有问题，从构建系统到ORM层。

虽然Graeme也承认任何插件系统都有可能出现问题——一个插件无法和另一个插件协同工作，不过他还是聊起了一些较为流行的插件：

有些插件已经流传甚广，也拥有着优秀的成长中的社区，例如JSecurity，Searchable（Compass集成），XFire和RichUI（Yahoo UI 集成）已经有了不错的口碑，发展势头也很迅速。

其他插件的发展速度比较慢，不过“已经死去”的插件却寥寥无几，这是个好信号。

他最后提到的就是在2007年10月人们所见证的G2One的成立，它为Groovy和Grails提供了培训服务和咨询：

从10月份成立以来，我们的效益一直特别好，目前我们的规模已经翻了一倍。这对于Groovy也是一个重大利好，可以看到它解决的问题数量有了一个飞升。

我们现在有很多全职或是兼职员工工作在每一个项目上，这把我们与那些打算采用Groovy但是还在寻求支持的人截然分开了。

社区中的反应纷纷从Jaiku和博客中传来，虽然大多数都是描述了这一发布的简单事实，但有些也在跟人们共享从前使用Grails的经验：

• Michael Kimsal 早已期盼着这次发布的到来：

  多少年我都没有像这样因为一次技术发布而如此兴奋了……从我去年春天开始使用0.5版到现在，Grails已经走过了很长的路。Graeme和他的那群人，嗯，就像一群训练有素的执法队员，在过去几个月内，为了1.0的发布干掉了狂多的bug，修复了几百个问题。

• 同时，Ray Kreuger建议Java开发人员应该近距离看一看Grails了：

  如果你是一个Java开发者，却对Grails或者Groovy不熟悉，你绝对应该把Grails的代码check out出来。Grails是一个基于“惯例重于配置”思想的快速Web应用开发框架。它的设计思想跟RoR十分相似，但它用的是Groovy语言。这种做法的最大好处是，Groovy是基于Java的，所以给人的感觉与Java很像，于是开发团队的学习成本就会很低。另外一点则是，它把应用构建为WAR文件，所以你可以把构建结果部署到任何一个旧的应用服务器上。不需要做什么黑客性质的工作。这对于在“企业性质”很重的环境下部署是很重要的。

• Bill Gloff的看法是，你不要管我说了什么，只管自己去试试看：

  Groovy和它的伙伴——Web框架Grails——在这些天里已经给人们带来了很多令人兴奋的消息，我知道为什么用它是一种快乐的体验，它会帮你成为一名效率更高的程序员。Grails从RoR那里借鉴了很多，但同时你还可以利用你掌握的Java与Java EE的知识。

• GroovyZone 也主张使用Grails：

  对我来说，Grails是Java上最快的原型开发平台。我仅仅是把那些现成的Hibernate配置好了的字节码文件丢进去，生成脚手架（scaffolding）视图，就已经完成了大量应用。它可以让你快速上手，把精力集中在正在构建的应用程序上。

• 最后，这场最近发生的对Rails和Grails进行对比的争论也许可以帮助你理解二者之间的差异：

  • Darryl West列举了从Rails转移到Grails上的10条理由。
  • Graeme Rocher附和说，Grails可以让Java开发者忘掉Rails。
  • 因在Rails方面的工作而出名的Relevance，把Graeme的观点归结成三部分，“转移的理由”，“边缘案例”和“屁话”。
  • Jens Krämer认为Graeme只是在祈求人们对Grails投入关注。

随着时间的推移，InfoQ会继续跟进对Groovy和Grails的报道。

查看英文原文：Grails 1.0 Released: ORM DSL, Filters, REST and more

• 更早的 >