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

Grails框架优劣势分析及同类比较,第1张

概述  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

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-06-08
下一篇 2022-06-08

发表评论

登录后才能评论

评论列表(0条)

保存