DRY 的思想是避免重复的信息。Grails中的DRY主要提现在URL映射定义上（URLMappings.groovy）。在 URLMappings.groovy中定义了应用的各个URL以后，通过使用Grails预定义的动态Controller方法和GSP标签，开发者就 不必再把程序URL硬编码在各处。比如使用GSP标签<g:createLink>，<g:createLinkTo> 和<g:link>，只需要提供Controller，Action和可选的参数，就能产生所需的URL。具体的用法可以查阅Grails文档 。
在约定优于配置方面，Grails和Rails非常相似。所谓约定优于配置，就是按照框架约定的方式来组织资源，就可以免去任何额外的配置。比如 Grails的自定义标签，存放在应用目录下的grails-app/taglib路径下，并以XXXTagLib.groovy的 方式命名，就能无需任 何配置就可以在GSP里使用这些标签库了。另外还有Service类，Job类，包括整个Grails应用的目录结构，都是约定由于配置原则的体现。在这 些方面JEE开发者一定会为摆脱各种繁琐的配置感到异常兴奋，并且实实在在的节约很多开发时间。
通过运行在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-pluginGrails就会下载相应的插件包并解压到本地Grails应用的插件路径下，并自动执行插件自带的安装脚本。
创建自己的插件也同样轻松。首先通过下面的命令自动建立插件项目
grails create-plugin fooGrails就会自动建立一个插件项目，包括一个FooPlugin.groovy的模板文件。编写Grails插件的具体方法可以阅读Grails插件开发文档。编写好了插件以后，准备发布到官方插件源上的话，首先注册一个codehaus帐号，成为Grails Plugins项目成员，并在官方邮件列表上申请发布权限。然后，只需要一条命令就可以自动发布到官方SVN源，提供给所有人下载了。
充分利用好已有的插件，可以进一步加快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框架的约定规则就能自动装入了。
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的例子。
OracleOracle早在JavaOne 06就宣布支持Grails/Groovy，Oracle官方也给出不少通过Grails使用旗下产品的文档：http://www.google.com/search?q=grails%20oracle。
SAPSAP提供了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和其他类似的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网站。