Rails 開發與 Java 編程的比較

 Ruby on Rails 開發和 Java 開發有著本質的不同。在 跨越邊界 系列的最後一期中，Bruce Tate 將概述使用 Rails 從頭開發一個複雜、可伸縮的 Web 網站時所發現的二者的主要差異。

     Rails 開發人員常常把 Java 開發人員看作是沉悶而勞碌的老古董。而 Java 崇拜者則常常認為 Ruby on Rails 只是一個玩具，根本不能用於任何嚴肅的軟體開發。作為一名對這兩種技術都有著廣泛使用經驗的顧問，我認為真實的情形介於這兩種觀點之間。由於跨越邊界 系列文章即將結束，因此我打算對它們再作一次比較。本文並非考察某種特殊的技術或語言，而是主要介紹我當前正在從事的項目，並將它與我以前從事的 Java 項目進行比較。另外，我建議您閱讀“跨越邊界”系列的前幾期文章，對相關主題作更深入的瞭解。這種直接的說明可讓您在二者之間權衡利弊，並可能使您在資料庫 Web 應用程式 green-field 的開發中通過使用 Rails 獲益。

業務問題

關於本系列 在 跨越邊界 系列文章中，作者 Bruce Tate 提出這樣一種觀點，當今的 Java 程式員們可以通過學習其他方法和語言更好地武裝自己。自從 Java 技術明顯成為所有開發項目最好的選擇以來，編程前景已經發生了改變。其他架構影響著 Java 架構的構建方式，從其他語言學到的概念也可以影響 Java 編程。您編寫的 Python（或 Ruby、Smalltalk 等語言）代碼可以改變編寫 Java 代碼的方式。 本系列介紹與 Java 開發完全不同的編程概念和技術，但是這些概念和技術也可以直接應用於 Java 開發。在某些情況下，需要整合這些技術來利用它們。在其他情況下，可以直接應用概念。具體的工具並不重要，重要的是其他語言和架構可以影響 Java 社區中的開發人員、架構，甚至是基本方式。

    不論是 Ruby on Rails 架構還是任何 Java 架構都不能解決所有問題。為了提高成功的幾率，需要長期、細緻地考察業務問題，理解周圍的各種假定情況，以及瞭解您的團隊。只有這樣才能選出正確的語言來進行開發。

    去年，Arvato Systems 聘請我帶領團隊構建 ChangingThePresent.org，它是一種新平台，用於將非贏利性團體和捐贈人組織在一起。與很多 Internet 公司一樣，我們向客戶展示了可購買的實際產品。與其他公司不同的是，這些 “產品” 指的是提供機會，比如：一名癌症研究員一小時服務收費 50 美元、協助盲人收費 30 美元，或者保護一英畝雨林一個月收費 20 美元。我們面臨兩大挑戰：一份很緊湊的時間表和長期的複雜性。

    開發工作從九月份開始，要求必須在十一月份之前建立起一個網站，以便有機會趕上聖誕節期間的通訊量高峰。（最終我們超出了十一月份這個期限兩星期。）在其他開發語言中，基於 Java 的解決方案可能要花費 6 到 18 個月才能完成這一任務。因此生產力是一個很重要的考慮因素，這與 Java 部署思想相悖。

    通過對競爭者和項目的考察，我們瞭解到：我們希望能夠每天給網站帶來幾百萬次點擊的通訊量。而我們需要每天有幾十萬次成功的點擊，因此延展性也是一個考慮因素。這與 Java 部署思想相符。

    最後，我們瞭解到：發布初始網站只是一個開始。我們只實現了總體規劃的百分之三。因此我們所選的技術需要根據複雜性和負載作出一些調整。我認為 Ruby 語言在複雜性方面會更易於調整，因為它提供了對更進階語言和特性（如開放類）的支援，以及具有更少配置需求和更簡單、整合化編程模型的 Rails 架構。

    雖然我們面臨著時間和延展性方面的挑戰，但是也擁有一些其他的有利因素。我們擁有一張完全空白的候選名單：可以選擇想要的任何技術、任何團隊。可以定義項目、培訓和全部的技術。我們可完全自由地作出選擇。

    Java 語言是一種優秀的通用語言。它總是應用於新的技術領域，如嵌入式系統和行動裝置。Java 語言在廣泛關注的整合方面也表現優秀。它具有高效能、流行並受到平台的良好支援。但是正如您在本系列中所瞭解到的那樣，Java 語言並不是用於資料庫支援的 Web 應用程式的 green-field 開發的最佳選擇。

    相比之下，Ruby on Rails 架構則是新的。並沒有很多人使用 Rails 開發高通訊流量的網站，並且幾乎不存在什麼使用 Rails 多年開發項目的經驗。但它仍然是一種高生產力的資料庫支援的 Web 應用程式開發的架構。最後，儘管我們對 Rails 缺乏開發長期項目的經驗和並未得到廣泛部署有所顧慮，但那份緊湊的時間表驅使我們選擇了 Ruby on Rails。

    作出這個決定之後，我們發現招募項目人才非常容易。我們還發現早期的生產力優勢非常顯著 —— 甚至比預期的還要好。我們確實遇到了一些早期的穩定性問題，因此加強了測試工作的力度。此後穩定性得到了極大的改進。

原理

    每個架構設計者都使用一組假定來構造該架構的重寫原理。學習遵守該原理的約束可使您愉快地進行編程，而挑戰這些約束則會使您的編程受挫。Rails 架構和 Java 架構擁有很多不同的原理。

    Rails 是一種整合架構，需要使用高度利用 Ruby 語言的動態本質。Rails 開發人員強調架構的生產力特性而不是工具特性，並且常常將 Web 架構看得非常簡單，在本系列的前幾篇文章中您已瞭解到這一點。Java 設計者通常必須分塊地組合開發環境，獨立地選擇持久性、Web 和整合層。他們通常嚴重地依賴工具來簡化核心任務。Web 架構設計趨向於較為複雜。

完全整合

    Java 架構往往是解決一個小問題（比如持久性或查看組織），而 Rails 則是一個Integration Environment。Rails 開發人員的優勢在於不必解決與許多不同框架組成的問題。大多數 Hibernate 開發人員陷入了過早關閉與 Java Web 架構之間的串連的陷阱。Rails 視圖架構是從頭構建的，以便與 ActiveRecord 整合（Rails 持久性架構）。當您考察用於 Web 服務、配置和外掛程式的 Rails 架構時也會發現類似的經驗。Java 編程支援各種不同的架構，對於所有這些架構使用不同的整合策略。

    Java 開發人員的優勢在於選擇。如果您需要從頭構建一個架構，則可能要考慮使用基於 SQL 的解決方案用於資料庫整合（如 iBATIS 或 Java 編程中基於 JDBC 的封裝架構之一）。反過來，如果要使用一種古老的模式進行編程，則可能要使用對象關係映射架構（如 Hibernate）。相比之下，如果您使用 Rails，則擁有一個主要選擇：ActiveRecord。這意味著 Java 架構提供了更多的選擇，有時能提供更好的整合開發項目的解決方案。但是由於我們要開發一個 green-field 項目，因此選擇算不上是一個問題。

一種動態語言

    Rails 原理的下一個主要部分是動態程式設計語言。Java 工具往往可以有效地使用 Java 類型模型提供的額外資訊。工具可以識別錯誤和有效地重構代碼。Rails 還可有效地利用程式設計語言的優點。Ruby 是一種構建特定領域語言（DSL）的理想語言。Rails 集中使用 DSL 來完成從構建模型對象之間的關係到指定自訂群組件（如狀態機器或可上傳的映像）的所有工作。動態語言常常更加簡潔，因此 Rails 項目比 Java 項目要簡練得多，可讓使用者更簡練地表達代碼和配置。在 ChangingThePresent.org 項目中，我們發現技術頂尖的程式員可達到更高的生產力，但是我們確實需要招募經驗更豐富的開發人員。我對這種妥協非常滿意。

    傳統的 Java 程式員對 IDE 有著近乎虔誠的熱愛，造成這一現象有充分的理由。IDE 提供了文法的完整性檢查、修正了小錯誤並提供了增量編譯以便更快地完成編碼、編譯、部署和測試這樣的周期。最近幾年來，開發環境開始更好地利用編譯迴圈和靜態類型提供的資訊。IDE 現在編輯抽象文法樹（AST），而不是（或者同時）編輯代碼的文本表示。這一策略允許使用強大的代碼重構工具，而使用靜態類型語言的同樣方法來實現此功能則困難得多。

    靜態類型確實能更好地使用工具，但是也存在缺點。強制使用靜態類型通常需要編譯器，而編譯步驟必然會降低生產力。使用 Rails，我可以更改一行代碼並重新載入瀏覽器，就可立即看到更改的結果。與 Java 開發人員相比，大多數 Ruby 開發人員只使用一種很好的編輯器。TextMate 是最流行的 Ruby on Rails 編輯器，它提供了文法反白、代碼完整性檢查，以及一些頻繁使用的結構的良好的模板支援。而當發現可將所有簡單的基於 Ruby 的指令碼（用作基本的 Rails 工具包）放入編輯器中時，您會更加喜出望外。與純粹的調試器不同的是，我可以使用斷點指令碼，該指令碼可停止特定的應用程式，進入一個 Ruby 解釋程式，我可在其中調用方法、檢查變數的值，以及甚至在恢複執行之間修改代碼。

簡單的架構

    傳統的 Web 端 Java 架構包括：一個用於域對象和Data Access Objects的層、一個提供業務級 API 的外觀層、一個控制器層和一個視圖層。此架構比典型的 “模型-視圖-控制器” 架構（使用 Smalltalk 語言最早建立）稍微複雜一些。相比之下，Ruby on Rails 包括一個使用 ActiveRecord 設計模式的模型層、一個控制器層和一個視圖層。我們喜歡易於獲得的 Rails 方法。它更加簡練並且帶來額外的複雜性和錯誤的機會更小。

慣例優先原則

    Java 架構通常可以自由地使用 XML 配置，而 Rails 主要使用慣例來避免可能的配置。在程式員必須指定配置的位置，Rails 通常依賴 Ruby（常常以 DSL 形式）來提供配置。對於 green-field 開發，我發現慣例優先於配置是很有意義的。該策略為我省去了很多行代碼，更簡化了必須編寫的代碼。估計我們所需的配置只有傳統 Java 應用程式中所指定的十分之一。我們有時會損失一點靈活性，但這並不足以抵消使用此策略帶來的節省。

    總而言之，Rails 架構的原理適合解決 ChangingThePresent.org 項目中的問題。整合的各種工具讓我可以利用架構實現更多的功能而無需自己進行過多的整合。“慣例優先原則” 為我節省了配置網站的時間。動態語言為經驗豐富的開發人員提供了更多的能力和靈活性，同時也使他們能夠利用更少的代碼錶達更強大的思想。該架構適合於我們團隊的能力和要解決的業務問題。

持久性

   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 被證明相當有效。我還不知道這個項目的最終規模如何，因為撰寫本文時該系統才運行 3 個月。現在只是開始增加通訊量。但是我們對生產力卻很瞭解。我知道團隊的預算比競爭公司（這些公司常常使用 Java 解決方案）的要低得多。我對我們的生產力也很有信心。

    通過跨越邊界 系列，我向您介紹了 Java 領域以外的語言和解決方案。但程式員畢竟是技術人員。每個高明的技術人員的工具包中都應包含適用於每個解決方案的廣泛的工具集。除工具外，本系列中介紹的觀點也為您展示了一些其他思路。現在一些架構設計者甚至將 Seaside、Rails 中的技術甚至 JavaScript 應用於 Java 架構中。找機會進行同樣的應用，繼續 “跨越邊界”。

關於作者

    Bruce Tate 是位父親、山地車手、皮艇手，住在德克薩斯州的奧斯汀。他是三本最暢銷 Java 圖書的作者，包括獲得 Jolt 獎的 Better, Faster, Lighter Java。他最近推出了 From Java to Ruby 和 Rails: Up and Running。他在 ibm 工作了 13 年，而後創立了 RapidRed 顧問公司，在那裡他專攻基於 Ruby 的輕量級開發策略和體繫結構及 Ruby on Rails 架構。現在他是 WellGood LLC 的 CTO ，該公司致力於為非盈利組織和福利機構開闢市場。