Ruby on Rails好像一直處于爭論的風口浪尖。大多數爭論的核心是其所宣稱的令人驚異的生產力。作者Bruce Tate已經開始理解Rails并不是一個更好的工具,而是一個不同類型的工具。本文研究了使Rails在某個領域如此高效率的折衷和設計決策。然后思索了應該在Java™社區獲得更多關注的受Rails啟發的思想。
Ruby on Rails(也叫做Rails)是一個針對支持數據庫的Internet應用程序的Ruby框架。我現在已經將Rails用于兩個不同的應用程序并涉及了另外兩個關聯的程序。為了即將完成的新書Java to Ruby,我已經采訪了很多Rails開發人員(那些在該框架上既成功也失敗過的人)、框架的創始人和Rails書籍的旗艦之作Agile Web Development with Rails的主要作者。我開始理解為什么Ruby on Rails架構如此成功?
炒作和懷疑論
在Java社區關于Rails的爭論已經相當激烈并且在將來一段時間沒有停止的跡象。Rails的支持者稱贊它的驚人的效率,與Java開發相比效率大約是10:1。作為Java程序員,您下意識的反應是不相信任何宣傳過高的效率,因為您可能以前聽到過這些,然而實際讓您很失望。Java 提倡者日益堅持Ruby on Rails是一個玩具,不能伸縮,會生成壞的代碼,并且只能開發簡單的應用程序。但是隨著對Rails的贊揚不斷出現(通常來自可信的來源),一項更加謹慎的任務是理解Rails能做好什么事情,并把它的思想帶回到Java平臺。
在本文中,將探究為Rails帶來巨大效率的核心特性。
Rails基本原理
Ruby on Rails框架不是大家所想的典型的應用程序開發框架。Rails的創始人David Heinemeier Hansson通常把該框架稱為固執己見的軟件,并且他喜歡打破長期存在的約定。David做出了非常有哲理性的決策并在整個框架中嚴格遵循這些決策。遍布于Rails內的核心觀點有:
◆無縫集成
Rails 聰明地利用了Ruby語言的最好特性。它擴展了Ruby,但您很難說出Ruby在哪里結束,Rails從哪里開始。您也可以看到Active Record(Rails 的持久引擎)和模型-視圖-控制器(MVC)框架之間進行了很好的集成。例如,您可以編寫三行代碼,創建一個表,然后立即為該模型生成用戶界面。
◆約定優于配置
為保持良好的靈活性,Java框架保持了大量普遍的配置文件。Rails不采用這種策略。它為方法、類、表和列采用普通的項目目錄結構和簡單普通的命名約定,以推斷哪些已配置在Java應用程序中。結果是Rails應用程序只需要對應Java應用程序的一小部分配置代碼,一般是十分之一或更多。
◆低重復
不要重復自己(Don't Repeat Yourself,DRY)是Rails社區的一個常見術語。Rails框架委員會使用通??雌饋硐袷荝uby語言的擴展的方法來把重復的任務抽象出來。Rails的元編程策略使每行代碼都執行更多的任務。
◆即時反饋
使用Rails,對于您所做的大多數工作都會給出即時反饋。編寫一行代碼并保存后,在加載下一個Web頁面時將激活您所做的更改。更新了您的數據庫以后,遷移可以向您即時顯示更改。
專注于某個領域
反對其宣稱的過高生產率的爭論通常類似于這樣:如果獲得了一把好的錘子,就很難找到另外一把生產率達到兩倍的錘子,更不用說把生產率提高5到10倍了,因為錘子已經發展演變幾千年了。但是把Ruby on Rails與各種通用目的的Java框架相比較的人是不得要領的。通過從根本上改變工具的本質可以在某些方面提高10倍的生產率?,F在專業的制造者使用釘子槍能夠在用錘子釘入一顆釘子的時間內釘入很多釘子。
像釘子槍一樣,Rails也是有專門用途的。它是一個專門編寫來用于單個領域的框架:新的支持數據庫的Web應用程序。
我猜想現今構建的應用程序有一半是支持數據庫且基于Web的應用程序。所以Rails是明確針對某領域的產品,但是這個領域很大也很重要。專攻此領域使Rails具有巨大的優勢,引起巨大轟動。通過專注于此領域的項目,Rails的設計者可以選擇一些其他框架不能或者不應該采用的捷徑。這種專門化往往為簡單性而失去靈活性。
新的支持數據庫的應用程序建議打包方法優于映射方法。Rails工具采用數據模型中的約定。Rails應用程序需要Java應用程序中創建的一小部分模型代碼。如果特別為Rails應用程序創建模式,此原則能工作得很好。如果試圖把遺留的模式塞入Rails中,將變得不太平滑。
基于Web的應用程序允許一組相似的優化。當您知道一個應用程序是基于Web的,您就能知道應用程序的大體結構和可能需要的主要組件。因為Rails關注的是基于Web的應用程序,所以在Rails中增強了以下功能:
◆模型-視圖-控制器
Rails的MVC框架(稱為Action Pack)為基于Web的訪問進行了定制并且實現了著名的被稱為Mode l2的設計策略。Rails版本已經優化了控制器和視圖之間的集成(該集成能夠使配置文件最小化)并且自動使控制器實例變量可供視圖使用。
◆項目目錄結構
所有Rails應用程序都具有相同的項目結構,其中的目錄用于存儲應用程序代碼、數據庫配置、公共的靜態文件,以及用于管理Web服務器和進行基于Web的功能測試的腳本。
◆架構
通過提供用于生成應用程序組件(這些組件都符合普通架構目標,比如頁面級和片段級緩存、兩層設計、用于測試、開發和生產的環境)的開箱即用腳本,Rails框架簡化了架構。
◆工具
Rails工具專門用于Web。日志支持、breakpointer、剖析器(profiler)和測試框架都針對基于Web的應用程序進行了修剪并針對兩層操作而被啟用。
但是釘子槍永遠不會取代錘子,我們卻愚蠢地希望能完全取代。錘子總能做一些釘子槍不能做的事情。
Rails將永遠不會成為用于企業集成、對象關系映射或全堆棧Web服務的工具。您可以對Rails所做的最好期望是,它是能很好滿足它所針對領域的專門工具。
開發人員實踐
當您開始透過表面深入研究下去時,您開始了解Rails開發人員實踐是如此的完全不同??焖俚姆答佒芷?、每次的交互控制和約定優于配置,這些都增強了在Java框架中不常用的那些方面的開發人員實踐。
反饋周期
影響開發人員生產率的最重要因素之一是總體反饋周期。反饋周期是從改變代碼到在屏幕上看到執行應用程序的結果所用的時間。在Rails中,能夠在編碼時得到即時的反饋。當您對Ruby代碼做出更改時,該功能十分顯著??梢粤⒓醇虞d一個瀏覽器頁面來查看更改以后的結果。因為在開發期間不需要編譯或部署,我傾向于在重新加載瀏覽器或執行測試用例之前只對編程做微小的更改。幾乎每個開始使用Rails的Java開發人員都以較小的程序塊進行編碼。
您可能認為對開發人員實踐友好的快速反饋周期不支持生產環境。畢竟,頻繁地重新加載類能夠獲得快速反饋周期,但是會使生產應用程序變得很慢。但是Rails通過為部署和開發提供不同的環境,避免了這個問題。在開發環境中以應用程序的性能為代價強制頻繁地重新加載類,而生產環境則把類的重新加載減少到最低限度,以開發人員的快速反饋周期為代價,為最終用戶提供快速的體驗。
共2頁: 1 [2] 下一頁 |
原文轉自:http://www.anti-gravitydesign.com