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

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

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开发者一定会为摆脱各种繁琐的配置感到异常兴奋，并且实实在在的节约很多开发时间。

相关厂商内容

深度案例解读，了解100件案例背后的思考 Top100summit案例分享：且看微信之海外精益创业 红点设计奖案例:施耐德创新电气设备系列策略与设计 QClub大连站：软件开发过程中的平台、技术选择（2013年11月23日 周六） 百度技术沙龙第四十四期： 大数据面面观（2013年11月23日周六） 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@H_502_69@ 
在官方源里看到了需要的插件名称（例如foo-plugin)，安装插件也只需要一条命令即可。
 
grails install-plugin foo-plugin@H_502_69@ 
Grails就会下载相应的插件包并解压到本地Grails应用的插件路径下，并自动执行插件自带的安装脚本。
 
创建自己的插件也同样轻松。首先通过下面的命令自动建立插件项目
 
grails create-plugin foo@H_502_69@ 
Grails就会自动建立一个插件项目，包括一个FooPlugin.groovy的模板文件。编写Grails插件的具体方法可以阅读Grails插件开发文档。编写好了插件以后，准备发布到官方插件源上的话，首先注册一个codehaus帐号，成为Grails Plugins项目成员，并在官方邮件列表上申请发布权限。然后，只需要一条命令就可以自动发布到官方SVN源，提供给所有人下载了。
 
grails release-plugin@H_502_69@ 
充分利用好已有的插件，可以进一步加快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@H_502_69@ 
自定义标签库文件存放于应用根路径下的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等类似框架相比，对手短期内无法达到的优势。
 没有银d 
软件开发过程没有银d，Grails也不是圣杯。虽然Grails拥有众多鲜明特点和优势，但目前来看也有不少缺点。
 JVM的部署环境 
JVM作为Grails的运行环境，是一把双刃剑。在性能出色的同时，JVM对于环境的要求使得Grails应用的部署环境比较有限。由于JVM的特殊 性，时至今日，性价比高的Java服务器依然屈指可数。相对于@R_419_6952@，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，包括 @R_419_6952@都属于现今最好的开源社区，活跃的社区对开源项目的成长起到巨大的作用。但是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%20oracle。
 SAP 
SAP提供了Composition on Grails产品，支持使用Grails和Groovy进行SAP产品的开发。
 linkedIn 
热门的商务SNS网站linkedIn有使用Grails进行开发的例子，曾经发布过@L_502_12@。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框架优劣势分析及同类比较全部内容，希望文章能够帮你解决Grails框架优劣势分析及同类比较所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。
					
										


					

						
欢迎分享，转载请注明来源：内存溢出
原文地址: http://outofmemory.cn/langs/1265533.html