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

关注

转载最新推荐文章于 2026-03-31 06:10:09 发布 2.8k 阅读 AI 写同款· GEO 优化 ›

28、Grails 升级指南与版本特性全解析本文详细解析了 Grails 从 1.2 到 2.0 的多个版本升级前需要检查的问题，并全面梳理了各版本的重要特性与变更。内容涵盖依赖管理、GORM 改进、插件部署、多数据源支持、代码热加载、单元测试优化等关键功能，同时列出了破坏性变更以帮助开发者顺利升级。通过本文，读者可以全面了解 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标签，和，只需要提供Controller，Action和可选的参数，就能产生所需的URL。具体的用法可以查阅Grails文档。

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

JVM

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

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贡献代码，一起把社区建设的更好。