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產品的開發。
熱門的商務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/
