Grails框架優劣勢

時間 2019-11-20

標籤 grails 框架優劣简体版

原文原文鏈接

原文地址：http://www.infoq.com/cn/articles/case-study-grails-partiihtml

  grails的思想
    1.Don't Repeat Yourself             不要重複你本身
    2.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。node

在約定優於配置方面，Grails和Rails很是類似。所謂約定優於配置，就是按照框架約定的方式來組織資源，就能夠免去任何額外的配置。好比 Grails的自定義標籤，存放在應用目錄下的grails-app/taglib路徑下，並以XXXTagLib.groovy的方式命名，就能無需任何配置就能夠在GSP裏使用這些標籤庫了。另外還有Service類，Job類，包括整個Grails應用的目錄結構，都是約定因爲配置原則的體現。在這些方面JEE開發者必定會爲擺脫各類繁瑣的配置感到異常興奮，而且實實在在的節約不少開發時間。程序員

JVM

經過運行在JVM之上，Grails擁有一個通過多年開發，已經很是成熟，業界標準級別的運行環境。JVM的穩定性和最新版本的性能都已經至關成熟。相比最直接的比較對象Rails，Grails在運行環境性能上的優點是比較明顯的。另外，已有的Java可重用組件基本均可以直接使用於Grails，無疑也是Grails的一個明顯優點。spring

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)，安裝插件也只須要一條命令便可。oracle

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貢獻代碼，一塊兒把社區建設的更好。