Grails 框架优劣势分析及同类比较

Grails 的优势

DRY（Don’t Repeat Yourself，不要重复自己），约定优于配置（Convention over Configuration）

DRY 和约定优先于配置的思想，是由 Rails 兴起并迅速被广泛接收和欣赏的 Web 框架新思路。Grails 作为 JEE 世界的 Rails，把这些最前沿的设计理念带入已显得陈旧的 JEE 社区，拥有鲜明突出的特点，以及由此带来的优秀的开发效率。

DRY 的思想是避免重复的信息。Grails 中的 DRY 主要提现在 URL 映射定义上（URLMappings.groovy）。在 URLMappings.groovy 中定义了应用的各个 URL 以后，通过使用 Grails 预定义的动态 Controller 方法和 GSP 标签，开发者就 不必再把程序 URL 硬编码在各处。比如使用 GSP 标签， 和

在约定优于配置方面，Grails 和 Rails 非常相似。所谓约定优于配置，就是按照框架约定的方式来组织资源，就可以免去任何额外的配置。比如 Grails 的自定义标签，存放在应用目录下的grails-app/taglib路径下，并以XXXTagLib.groovy的方式命名，就能无需任 何配置就可以在 GSP 里使用这些标签库了。另外还有 Service 类，Job 类，包括整个 Grails 应用的目录结构，都是约定由于配置原则的体现。在这 些方面 JEE 开发者一定会为摆脱各种繁琐的配置感到异常兴奋，并且实实在在的节约很多开发时间。

JVM

通过运行在 JVM 之上，Grails 拥有一个经过多年开发，已经非常成熟，业界标准级别的运行环境。JVM 的稳定性和最新版本的性能都已经相当成熟。相比 最直接的比较对象 Rails，Grails 在运行环境性能上的优势是比较明显的。另外，已有的 Java 可重用组件基本都可以直接使用于 Grails，无疑 也是 Grails 的一个明显优势。

Groovy 语言

Grails 和 Groovy 语言的关系是密不可分的。对于 Groovy 来说，Grails 是其最大的杀手级应用。而对 Grails 来说，Groovy 是其能够实现灵活多变的快速开发，区别于其他运行于 JVM 之上的 Web 框架的核心技术。

Groovy 的动态特性是其最大亮点，在这方面几乎不输于 Ruby 等其他热门的动态语言。meta-programming，closure 等等热门的动 态语言特性在 Groovy 中都有很好的实现。而且，Groovy 程序能够编译为 JVM 字节码的.class 文件，直接运行在 JVM 上，Groovy 程序的 性能能够得到一定的帮助。Groovy 能够和 Java 混合编写，混合编译，使得 Java 程序员能不用浪费自己在 Java 语言上的大量投入，更轻松快捷地进 入 Groovy 的世界。使用 Groovy 编程，相比使用 Java 来说快速轻松得多，对为数众多的 Java 程序员颇有吸引力。

插件系统

Grails 的插件系统也是其亮点之一。首先，和 Rails，Django 等 Web 框架类似，基于微内核的思想，插件（可重用模块）是框架的一等公民。 Grails 除了核心模块以外的功能几乎都是通过插件方式实现的。实际上，一个 Grails 插件和一个 Grails 应用基本是完全一样的，同样可以使用grails run-app命令来运行。区别仅在于一个插件的根目录下需要提供一个FooPlugin.groovy文件，提供插件的一些描述信息。

Grails 插件基本可以做任何事情，Grails 社区已经提供了各式各样的插件，发布在 Grails 官方插件源上。查看现有的官方插件，可以执行下面的命令。

 
grails list-plugins

在官方源里看到了需要的插件名称（例如 foo-plugin)，安装插件也只需要一条命令即可。

 
grails install-plugin foo-plugin

Grails 就会下载相应的插件包并解压到本地 Grails 应用的插件路径下，并自动执行插件自带的安装脚本。

创建自己的插件也同样轻松。首先通过下面的命令自动建立插件项目

 
grails create-plugin foo

Grails 就会自动建立一个插件项目，包括一个FooPlugin.groovy的模板文件。编写 Grails 插件的具体方法可以阅读 Grails 插件开发文档。编写好了插件以后，准备发布到官方插件源上的话，首先注册一个 codehaus 帐号，成为 Grails Plugins 项目成员，并在官方邮件列表上申请发布权限。然后，只需要一条命令就可以自动发布到官方 SVN 源，提供给所有人下载了。

 
grails release-plugin

充分利用好已有的插件，可以进一步加快 Grails 开发过程。比如我在开发 feedlr 过程中就使用了 Quartz，Searchable，Feeds，OpenID 等插件，而且编写并发布了 OAuth 插件。

GSP 和标签库

Grails 前端开发使用的是 GSP（Grails Server Pages），开发者可以使用 Grails 特定的模板语法编写 gsp 动态页面，并且可以直接使用 Groovy 脚本或是各种预定义和自定义的标签库 （taglib）。这么看起来和 JSP 区别不大，而实际上，Grails 带给开发者的是远比名字上的区别大得多的开发效率上的进步。

首先，虽然不是推荐的做法，但是直接在 GSP 中使用 Groovy 脚本的话就直接利用了 Groovy 快速开发的优势。

另外，JEE 开发者对于 JSP 标签库的易用性大多有所诟病，常常需要做貌似多余的各种配置。而 Grails 通过 DRY 和约定优先于配置的思想，使得 GSP 标签库的易用性非常棒。框架预定义的标签库自然是什么配置都不需要就可以直接使用了，而利用了 Groovy 的动态特性的标签语法，可以相当程度地减少编码 量。

编写自定义标签相对于 JSP 更是异常轻松。只需要通过以下命令新建自定义标签库文件，通过 groovy 的 closure 方式编写自定义标签，之后什么配置都不需要，就可以直接在 GSP 中使用新建的自定义标签了。

 
grails create-tag-lib

自定义标签库文件存放于应用根路径下的grails-app/taglib目录下，命名规范为XXXTagLib.groovy，通过 Grails 框架的约定规则就能自动装入了。

成熟的 JEE Stack

Grails 是一个整合了若干已有 JEE 组件和框架而成的，其中包括了 Spring，Spring Workflow，Hibernate，SiteMesh，JUnit，Ant 等。这些都是已经相当成熟的开源组件，是开源 JEE Stack 的事实规范。通过以这些组件为基础，Grails 直接就能在企业应用市场占有一定地位。而社区更是为 Grails 贡献了不少其他 JEE 开源组件 的插件。对于企业来讲，Grails 直接就是一个很有吸引力的快速原型开发框架，可以直接和广泛使用的已有技术很好的整合。这点可能是 Grails 和 Rails 等类似框架相比，对手短期内无法达到的优势。

没有银弹

软件开发过程没有银弹，Grails 也不是圣杯。虽然 Grails 拥有众多鲜明特点和优势，但目前来看也有不少缺点。

JVM 的部署环境

JVM 作为 Grails 的运行环境，是一把双刃剑。在性能出色的同时，JVM 对于环境的要求使得 Grails 应用的部署环境比较有限。由于 JVM 的特殊 性，时至今日，性价比高的 Java 服务器依然屈指可数。相对于 PHP，Python，甚至 Ruby 的眼花缭乱的廉价服务器选择，Grails 开发者只能眼 红了。这样带来的问题是使用 Grails 技术的话部署应用的起步成本高，对独立开发者以及对成本敏感的小型创业公司来讲，起步阶段就大多会采用性价比更高 的其他技术。

复合型框架带来的整合复杂性

Grails 使用多种已有的成熟开源 JEE 组件，同样是一把双刃剑。多种组件整合在一起，出现整合方面的问题的话调试修改都会比较吃力。典型的例子是 Grails 出错的 stack trace，往往会包括了从下层 JEE 框架抛出的大量异常信息，这些噪音对分析问题造成干扰，对一些疑难问题的解决会造成困难。而且这些底层组件都是传统 的 JEE 组件，调试起来丝毫无法利用到 Groovy 和 Grails 的灵活方便的优点。

开发工具的欠缺

Grails 开发使用什么 IDE，这是大多开发者接触 Grails 时最先提出的问题。可惜的是，这个问题至今没有令人信服的答案。在官方邮件列表上，推荐 比较多的是 IntelliJ IDEA，其他可选的是 Eclipse，Netbeans。IDEA 相对来讲对于 Groovy/Grails 的支持确实做得最全面，但是对于习惯于开源 IDE 的大多数 JEE 开发者来说，切换到另一个陌生的而且购买费用不低的 IDE 是个不小的代价，而对于企业来讲为此花钱更换开发环境更是个不小的障碍。 Eclipse 和 Netbeans 的 Groovy/Grails 支持至今还是比较初步和不稳定，而且进展也相当缓慢。目前我个人更倾向于使用 Mac TextMate 加上 Groovy Grails Bundle。但这并不是一个适合所有人的答案。

尚不成熟的社区

这可能是 Grails 最关键的隐藏的弱点。一个开源项目的成功与否很大程度上取决于其社区。Rails/Ruby，Django/Python，包括 PHP 都属于现今最好的开源社区，活跃的社区对开源项目的成长起到巨大的作用。但是 Grails 的社区至今还是相当小众，在人数和质量上都无法和以上三大 社区相比。一个不成熟的社区带来的一个明显问题就是 Grails 项目的开发进度比较慢，相关文档和资料缺乏 >

敏捷开发框架横向比较：Grails，Rails，Django

性能

和使用 Ruby 语言的 Rails 以及使用 Python 语言的 Django 相比，使用 Groovy 语言的 Grails 可以利用到其整合的 JEE 组件和 JVM 本身的性能优势。而在性能是关键的时候，还可以直接使用 Java。

Grails 项目负责人 Graeme Rocher 做过一个比较细致的 Grails 和 Rails 性能对比评测。 在 Grails 0.5 和 Rails 1.2.3 的对比测试中，在包括数据 CRUD 操作在内的所有项目中 Grails 全面超越 Rails，某些项目的优势可以达到 40%-50%。不过这个测试 是在 07 年初做的，目前已经比较过时，两个项目也已经经历了不少更新。但是基本上说，借助了 JVM 性能优势的 Grails 相比 100% 纯 Ruby 的 Rails 还是在微观性能测试中占有一定上风。

由于 Ruby 默认运行时 VM 的性能一般，Django 采用的 Python 语言在微性能测试中也要胜于 Ruby，但是 Grails 和 Django 的直接对比目前似乎还没有详细可靠的资料。

开发效率

这三种框架在设计理念上基本是一致的：DRY（Don’t Repeat Yourself，不要重复自己）和约定优于配置（Convention over Configuration），所以在开发效率上三者基本不相上下。

另外值得一提的是，Groovy 语言本身的特点也使其开发效率比 Java 高出不少，和其他流行动态语言不相上下，对 Grails 的开发效率功不可没。Grails 框架内提供的魔法般的动态方法都是通过 Groovy 元编程实现的，包括约定优于配置 中 Service 类的自动注入，builder，codecs 等的实现等等。由于篇幅有限此处无法做进一步举例，大家可以从 Groovy 主页得到详细的资料。

部署

应用的部署可能是这三种框架区别最大的一点。

对于 Grails，基本可以部署在任何 Java Servlet 容器环境下。而在实际情况中，廉价的 Java 服务器选择很少，一般只能采用 VPS 或者独立主机的方式部署。而 JVM 对内存的要求也不低。虽 然有不少在 256MB 内存的环境下运行 Grails 的例子，但是要达到实用的性能的话，至少 512MB 的内存是必须的。比如 Feedlr 是部署在一台 540MB 内存的 VPS 服务器上（由 Linode 提供）。

Rails 由于其快速窜红，目前可选的部署服务已经不少了。除了 VPS 和独立主机外，直接支持 Rails 的廉价共享主机，甚至 Rails 云计算服务（Heroku）都是不错的选择。

和 Rails 一样，Django 的部署服务选择也不少。从廉价的共享主机到云计算服务，特别值得一提的是支持 Django 的 Google App Engine 服务，是一个很有吸引力的选择。

社区

在本系列上文中提到了 Grails 在开源社区方面的劣势。Grails 目前还是一个很年轻的项目，而 Groovy 也还是一个年轻而小众的语言。在社区方面，Grails 的劣势是比较明显的。

Rails 社区是三者中最热闹的。在偶像级人物 DHH 的带领下，Rails 的发展确实让人刮目相看。Django 的社区依托了历史悠久而成熟的 Python 社区，也 发展的相当成熟。成熟的开源社区的一大标志就是有众多高质量的社区代码，包括社区开发的组件和贡献的代码。在这方面 Rails 和 Django 都非常典型， 两者目前都已经依托社区建立其了一定规模的核心开发团队。而 Grails 目前还是主要由 G2One 团队进行开发，从项目进度来看资源比较紧缺，新版本发布 常被推迟。我在开发 Feedlr 过程中曾为 Grails 提交过几个补丁和发布了 OAuth 插件，在此过程中也感觉 Grails 还需要更多来自社区的帮助。 在此也希望各位爱好 Grails 的朋友能多多为 Grails 贡献代码，一起把社区建设的更好。

Grails 的现状和未来

Grails 目前主要被少数独立开发者和小型网站采用，另外在使用 JEE 的大型公司中也有不少使用 Grails 进行快速原型开发和试验性项目，包括 Oracle，SAP 等都有使用 Grails 的例子。

Oracle

Oracle 早在 JavaOne 06 就宣布支持 Grails/Groovy，Oracle 官方也给出不少通过 Grails 使用旗下产品的文档： http://www.google.com/search?q=grails oracle。

SAP

SAP 提供了 Composition on Grails 产品，支持使用 Grails 和 Groovy 进行 SAP 产品的开发。

LinkedIn

热门的商务 SNS 网站 LinkedIn 有使用 Grails 进行开发的例子，曾经发布过招聘Grails 工程师的广告。 LinkedIn 官方博客还曾专门介绍过使用 Grails 进行内部开发的经验。

更多 Grails 网站的例子

Grails 官方 Wiki 提供了更多使用 Grails 搭建的网站的例子： http://grails.org/Success+Stories

总的来说，由于 Grails 基于 JEE 的架构，企业市场接受 Grails 的速度比 Rails 更胜一筹。但目前 Grails 还没有较大规模和影响的实际案例，企业采用 Grails 也尚处于尝试阶段。而 Grails 部署服务的选择还是不多，但是值得一提的是最近出现的 Morph Labs 提供的云计算服务，直接支持 Grails 的部署。相信如果配套的部署服务跟上的话，Grails 会得到更多开发者的青睐，并且涌现更多有意思的实际网站案例的。

Groovy 和 Grails 诞生以来一直作为独立的开源社区项目存在，并没有商业支持。在 07 年 9 月，Grails 和 Groovy 各自的项目负责人合作成立了 G2One 公司，专为 Grails 和 Groovy 技术提供背后的支持并进行商业化运作。而在 08 年 11 月， SpringSource 宣布收购 G2One 。这样，以 Spring 为基础的 Grails 正式进入了 Spring 家族，结束了漂流生涯。这对于 Grails 以及 Groovy 社区都是一个非常好的消 息。独立开源项目往往受到资金，人力等问题的困扰，而有了商业公司的支持，项目可以拥有全职开发人员，可以有市场推广的预算，并且通过 Spring 的品牌 和市场占有率，更能提高 Grails 和 Groovy 的知名度和业界影响。在 09 年，随着收购过渡的完成，我们期待 Spring 给 Grails 带来的改变， 而带给开发者一个更出色更成熟的开发工具。

总结

Grails 是个特色鲜明的 Web 开发框架。作为一个年轻的开源框架，它有吸引人的特点，但还并不完美。

参考资料

• Grails： http://grails.org
• Grails 文档： http://grails.org/doc/1.0.x/
• Grails 插件： http://www.grails.org/Plugins
• Groovy： http://groovy.codehaus.org/
• G2One： http://www.g2one.com
• SpringSource 收购公告： http://www.springsource.com/g2one
• Morph Labs： http://mor.ph

作者简介

侯雍容，毕业于复旦大学计算机专业，毕业后在 IBM 中国开发中心从事软件开发工作，目前创立了上海睿谷信息科技有限公司，从事 软件开发和咨询工作。对于敏捷 Web 开发、动态程序语言、云计算等方面都有特别的兴趣和经验。可以从这里看到关于他的详细资 料： http://www.linkedin.com/in/houyr 也可以访问他的个人博客： http://damienh.org 。

相关阅读：案例研究──利用Grails 搭建Feedlr.com 网站。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。