年 月 日
Ruby on Rails 開發和 Java&#; 開發有著本質的不同在跨越邊界 系列的最後一期中Bruce Tate 將概述使用 Rails 從頭開發一個復雜可伸縮的 Web 站點時所發現的二者的主要差異
Rails 開發人員常常把 Java 開發人員看作是沉悶而勞碌的老古董而 Java 崇拜者則常常認為 Ruby on Rails 只是一個玩具根本不能用於任何嚴肅的軟件開發作為一名對這兩種技術都有著廣泛使用經驗的顧問我認為真實的情形介於這兩種觀點之間由於跨越邊界 系列文章即將結束因此我打算對它們再作一次比較本文並非考察某種特殊的技術或語言而是主要介紹我當前正在從事的項目並將它與我以前從事的 Java 項目進行比較另外我建議您閱讀跨越邊界系列的前幾期文章對相關主題作更深入的了解這種直接的說明可讓您在二者之間權衡利弊並可能使您在數據庫 Web 應用程序 greenfield 的開發中通過使用 Rails 獲益
業務問題
關於本系列
在 跨越邊界 系列文章中作者 Bruce Tate 提出這樣一種觀點當今的 Java 程序員們可以通過學習其他方法和語言更好地武裝自己自從 Java 技術明顯成為所有開發項目最好的選擇以來編程前景已經發生了改變其他框架影響著 Java 框架的構建方式從其他語言學到的概念也可以影響 Java 編程您編寫的 Python（或 RubySmalltalk 等語言）代碼可以改變編寫 Java 代碼的方式 本系列介紹與 Java 開發完全不同的編程概念和技術但是這些概念和技術也可以直接應用於 Java 開發在某些情況下需要集成這些技術來利用它們在其他情況下可以直接應用概念具體的工具並不重要重要的是其他語言和框架可以影響 Java 社區中的開發人員框架甚至是基本方式
不論是 Ruby on Rails 框架還是任何 Java 框架都不能解決所有問題為了提高成功的幾率需要長期細致地考察業務問題理解周圍的各種假定情況以及了解您的團隊只有這樣才能選出正確的語言來進行開發
去年Arvato Systems 聘請我帶領團隊構建 Ch它是一種新平台用於將非贏利性團體和捐贈人組織在一起與很多 Internet 公司一樣我們向客戶展示了可購買的實際產品與其他公司不同的是這些 產品 指的是提供機會比如一名癌症研究員一小時服務收費 美元幫助盲人收費 美元或者保護一英畝雨林一個月收費 美元我們面臨兩大挑戰一份很緊湊的時間表和長期的復雜性
開發工作從九月份開始要求必須在十一月份之前建立起一個站點以便有機會趕上聖誕節期間的通信量高峰（最終我們超出了十一月份這個期限兩星期）在其他開發語言中基於 Java 的解決方案可能要花費 到 個月才能完成這一任務因此生產力是一個很重要的考慮因素這與 Java 部署思想相悖
通過對競爭對手和項目的考察我們了解到我們希望能夠每天給站點帶來幾百萬次點擊的通信量而我們需要每天有幾十萬次成功的點擊因此可伸縮性也是一個考慮因素這與 Java 部署思想相符
最後我們了解到發布初始站點只是一個開始我們只實現了總體規劃的百分之三因此我們所選的技術需要根據復雜性和負載作出一些調整我認為 Ruby 語言在復雜性方面會更易於調整因為它提供了對更高級語言和特性（如開放類）的支持以及具有更少配置需求和更簡單集成化編程模型的 Rails 框架
雖然我們面臨著時間和可伸縮性方面的挑戰但是也擁有一些其他的有利因素我們擁有一張完全空白的候選名單可以選擇想要的任何技術任何團隊可以定義項目培訓和全部的技術我們可完全自由地作出選擇
Java 語言是一種優秀的通用語言它總是應用於新的技術領域如嵌入式系統和移動設備Java 語言在廣泛關注的集成方面也表現優秀它具有高性能流行並受到平台的良好支持但是正如您在本系列中所了解到的那樣Java 語言並不是用於數據庫支持的 Web 應用程序的 greenfield 開發的最佳選擇
相比之下Ruby on Rails 框架則是新的並沒有很多人使用 Rails 開發高通信流量的站點並且幾乎不存在什麼使用 Rails 多年開發項目的經驗但它仍然是一種高生產力的數據庫支持的 Web 應用程序開發的框架最後盡管我們對 Rails 缺乏開發長期項目的經驗和並未得到廣泛部署有所顧慮但那份緊湊的時間表驅使我們選擇了 Ruby on Rails
作出這個決定之後我們發現招募項目人才非常容易我們還發現早期的生產力優勢非常顯著 —— 甚至比預期的還要好我們確實遇到了一些早期的穩定性問題因此加強了測試工作的力度此後穩定性得到了極大的改進
原理
每個框架設計者都使用一組假定來構造該框架的重寫原理學習遵守該原理的約束可使您愉快地進行編程而挑戰這些約束則會使您的編程受挫Rails 框架和 Java 框架擁有很多不同的原理
Rails 是一種集成框架需要使用高度利用 Ruby 語言的動態本質Rails 開發人員強調框架的生產力特性而不是工具特性並且常常將 Web 架構看得非常簡單在本系列的前幾篇文章中您已了解到這一點Java 設計者通常必須分塊地組合開發環境獨立地選擇持久性Web 和集成層他們通常嚴重地依賴工具來簡化核心任務Web 架構設計趨向於較為復雜
完全集成
Java 框架往往是解決一個小問題（比如持久性或查看組織）而 Rails 則是一個集成環境Rails 開發人員的優勢在於不必解決與許多不同框架集成的問題大多數 Hibernate 開發人員陷入了過早關閉與 Java Web 框架之間的連接的陷阱Rails 視圖框架是從頭構建的以便與 ActiveRecord 集成（Rails 持久性框架）當您考察用於 Web 服務配置和插件的 Rails 框架時也會發現類似的經驗Java 編程支持各種不同的框架對於所有這些框架使用不同的集成策略
Java 開發人員的優勢在於選擇如果您需要從頭構建一個框架則可能要考慮使用基於 SQL 的解決方案用於數據庫集成（如 iBATIS 或 Java 編程中基於 JDBC 的包裝框架之一）反過來如果要使用一種古老的模式進行編程則可能要使用對象關系映射框架（如 Hibernate）相比之下如果您使用 Rails則擁有一個主要選擇ActiveRecord這意味著 Java 框架提供了更多的選擇有時能提供更好的集成開發項目的解決方案但是由於我們要開發一個 greenfield 項目因此選擇算不上是一個問題
一種動態語言
Rails 原理的下一個主要部分是動態編程語言Java 工具往往可以有效地使用 Java 類型模型提供的額外信息工具可以識別錯誤和有效地重構代碼Rails 還可有效地利用編程語言的優點Ruby 是一種構建特定於域的語言（DSL）的理想語言Rails 集中使用 DSL 來完成從構建模型對象之間的關系到指定自定義組件（如狀態機器或可上傳的圖像）的所有工作動態語言常常更加簡潔因此 Rails 項目比 Java 項目要簡練得多可讓用戶更簡練地表達代碼和配置在 Ch 項目中我們發現技術頂尖的程序員可達到更高的生產力但是我們確實需要招募經驗更豐富的開發人員我對這種妥協非常滿意
傳統的 Java 程序員對 IDE 有著近乎虔誠的熱愛造成這一現象有充分的理由IDE 提供了語法的完整性檢查修正了小錯誤並提供了增量編譯以便更快地完成編碼編譯部署和測試這樣的周期最近幾年來開發環境開始更好地利用編譯循環和靜態類型提供的信息IDE 現在編輯抽象語法樹（AST）而不是（或者同時）編輯代碼的文本表示這一策略允許使用強大的代碼重構工具而使用靜態類型語言的同樣方法來實現此功能則困難得多
靜態類型確實能更好地使用工具但是也存在缺點強制使用靜態類型通常需要編譯器而編譯步驟必然會降低生產力使用 Rails我可以更改一行代碼並重新加載浏覽器就可立即看到更改的結果與 Java 開發人員相比大多數 Ruby 開發人員只使用一種很好的編輯器TextMate 是最流行的 Ruby on Rails 編輯器它提供了語法突出顯示代碼完整性檢查以及一些頻繁使用的結構的良好的模板支持而當發現可將所有簡單的基於 Ruby 的腳本（用作基本的 Rails 工具包）放入編輯器中時您會更加喜出望外與純粹的調試器不同的是我可以使用斷點腳本該腳本可停止特定的應用程序進入一個 Ruby 解釋程序我可在其中調用方法檢查變量的值以及甚至在恢復執行之間修改代碼
簡單的架構
傳統的 Web 端 Java 架構包括一個用於域對象和數據訪問對象的層一個提供業務級 API 的外觀層一個控制器層和一個視圖層此架構比典型的 模型視圖控制器 架構（使用 Smalltalk 語言最早創建）稍微復雜一些相比之下Ruby on Rails 包括一個使用 ActiveRecord 設計模式的模型層一個控制器層和一個視圖層我們喜歡易於獲得的 Rails 方法它更加簡練並且帶來額外的復雜性和錯誤的機會更小
慣例優先原則
Java 框架通常可以自由地使用 XML 配置而 Rails 主要使用慣例來避免可能的配置在程序員必須指定配置的位置Rails 通常依賴 Ruby（常常以 DSL 形式）來提供配置對於 greenfield 開發我發現慣例優先於配置是很有意義的該策略為我省去了很多行代碼更簡化了必須編寫的代碼估計我們所需的配置只有傳統 Java 應用程序中所指定的十分之一我們有時會損失一點靈活性但這並不足以抵消使用此策略帶來的節省
總而言之Rails 框架的原理適合解決 Ch 項目中的問題集成的各種工具讓我可以利用框架實現更多的功能而無需自己進行過多的集成慣例優先原則 為我節省了配置站點的時間動態語言為經驗豐富的開發人員提供了更多的能力和靈活性同時也使他們能夠利用更少的代碼表達更強大的思想該框架適合於我們團隊的能力和要解決的業務問題
持久性
Java 和 Ruby 語言的最流行的持久性框架可以比任何其他特性更好地闡明 Java 和 Ruby 經驗之間的區別Java 開發人員通常使用 Hibernate它是一種對象關系映射框架通過 Hibernate您可獲取現有的模型和模式並使用注釋或 XML 表達二者之間的映射Hibernate 類是簡單傳統 Java 對象（POJO）它的每個對象派生自一個通用的基類大多數配置是顯式的使用注釋XML 或二者的某種結合
而 ActiveRecord 是一種包裝的框架就是說每個類都是現有類的包裝器ActiveRecord 根據關聯表的內容（如表中每列的一個屬性）自動地向模型對象添加特性所有的類都從一個通用的基類繼承ActiveRecord 主要利用通用約定來推斷配置例如
ActiveRecord 利用類名的復數形式來推出表名
主鍵的名稱為
id
列表的排序順序由
position 字段決定
對象關系映射是使用遺留模式（可能定義時沒有考慮對象模型）時的最佳解決方案但是當您能為應用程序顯式地設計數據庫模式時您通常不需要映射框架了我們將 ActiveRecord 看作我們的一個巨大優點我們可以包含關系數據庫需要時轉入 SQL 並在適當的時候退出
遷移
Rails 遷移使我們能夠用代碼表示模式的兩個版本之間的差別和它們所包含的數據之間的差別對每個遷移都進行了命名和編號可在任何時候恢復到任何版本遷移有以下一些確切的優點
產生錯誤代碼時可恢復到一個舊版本的模式
用代碼而不是 SQL 來表達模式
更便於我們使用
在最大程度上與數據庫獨立
但是遷移也有一些限制如果兩個開發人員同時創建遷移則編號會出現混亂所以我們必須手動處理我們通過有效的通信來使這些問題最小化團隊成員構建需使用遷移的新模型時發出通知但是這個模型依賴於團隊的開發人員較少或遷移進展較慢的情況
ActiveRecord 還有其他的限制其中一些是故意作出的Rails 的創建者認為數據庫的約束和組成應歸入應用程序而不是數據庫這種思想帶來了一些副作用ActiveRecord 使用視圖的情況不是很好構建過程（克隆模式復制測試數據並運行測試）並不能正確地進行復制ActiveRecord 在使用參考完整性約束的某些場合也會出現問題因為某些類型的關聯可能連接到多個數據庫表跨越復雜模型進行預先加載很復雜通常在連接多行時需要使用 SQL繼承也受到限制使用 ActiveRecord 時我被迫使用單表繼承 映射策略而該策略並不總是最佳選擇
所有的持久性策略都充滿了妥協我認為 ActiveRecord 實現了一組有效的妥協常常選擇了簡單性總而言之ActiveRecord 和遷移是我們的積極推動我們可以快速地構建解決方案我們擁有足夠的 SQL 訪問權可在需要時改進系統性能但是當 ActiveRecord 並不總能應對挑戰時最好將 Rails 應用於使用老舊模式的項目一些替代的持久性模型正在出現包括 RBatis一種 iBATIS Java 框架的端口現在討論 RBatis 的有效性還為時過早
結束語
對於我的團隊和項目來說Ruby on Rails 被證明相當有效我還不知道這個項目的最終規模如何因為撰寫本文時該系統才運行 個月現在只是開始增加通信量但是我們對生產力卻很了解我知道團隊的預算比競爭公司（這些公司常常使用 Java 解決方案）的要低得多我對我們的生產力也很有信心
通過跨越邊界 系列我向您介紹了 Java 領域以外的語言和解決方案但程序員畢竟是技術人員每個高明的技術人員的工具包中都應包含適用於每個解決方案的廣泛的工具集除工具外本系列中介紹的觀點也為您展示了一些其他思路現在一些框架設計者甚至將 SeasideRails 中的技術甚至 JavaScript 應用於 Java 框架中找機會進行同樣的應用繼續 跨越邊界
關於作者
Bruce Tate 是位父親山地車手皮艇手住在德克薩斯州的奧斯汀他是三本最暢銷 Java 圖書的作者包括獲得 Jolt 獎的 Better Faster Lighter Java他最近推出了 From Java to Ruby 和 Rails: Up and Running他在 IBM 工作了 年而後創立了 RapidRed 顧問公司在那裡他專攻基於 Ruby 的輕量級開發策略和體系結構及 Ruby on Rails 框架現在他是 WellGood LLC 的 CTO 該公司致力於為非盈利組織和福利機構開辟市場
From:http://tw.wingwit.com/Article/program/Java/hx/201311/26713.html
