程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> JAVA編程 >> 關於JAVA >> Grails框架優劣勢分析及同類比較

Grails框架優劣勢分析及同類比較

編輯:關於JAVA

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標簽<g:createLink>,<g:createLinkTo> 和<g:link>,只需要提供Controller,Action和可選的參數,就能產生所需的URL。具體的用法可以查閱Grails文檔 。

在約定優於配置方面,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%20oracle。

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和其他類似的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/

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved