從EJB到Spring：企業級組件化思想的傳承與實踐

前言：被誤解的「冤家」關係

提到 EJB 與 Spring，許多 Java 開發者腦海中浮現的是「兩大冤家」的對立形象。然而，若深入探究其技術脈絡，Spring 實際上是 EJB 1.x/2.x 的繼承者，正如 EJB 承接了 COM、CORBA 的衣缽。它們的核心思想一脈相承——企業級組件化思想，這也是軟體工程追求的理想境界。

一、 國內軟體業的「非組件化」困境

低水平重複的惡性循環

企業核心業務長期穩定，新業務圍繞核心展開。然而 IT 技術變遷與業務擴展間存在巨大矛盾：新業務上線如何不影響舊系統？技術升級如何平滑遷移？如何重用既有技術資產？在組件化思想普及前，這幾乎是死結，絕大多數做法只能是重寫。

從 DOS 時代的 FoxBase 財務系統，到 Windows 時期的 VB/PB 重寫，再到 B/S 架構、近年熱門的 RIA，每次技術浪潮都伴隨著系統的全盤重寫。這被稱為「低水平重複」——企業重複投資、開發者重複學習、數據重複遷移，最終導致系統與業務脫節，優秀開發者因追趕技術而忽視業務深度，產業長期無法積累，淪為「吃外國剩飯」的局面。

為什麼應用系統不如作業系統穩健？

我們更換外設、記憶體、顯卡從不換主機；作業系統支援萬種程式並相容舊版；但我們的應用系統換個環境就得重寫？根因在於規範性太低、耦合度太高。提高規範、降低耦合，需不斷分層、抽象、重構，將成熟代碼封裝為可重用的 Jar/DLL，這才是合格代碼的標誌。

國內產業的「組裝」困境

外國熱衷製造零件（組件），國內熱衷組裝零件。「不重複造輪子」成了口號，卻既造不出舊輪子，也發明不出新輪子。RAD（快速應用開發）誘使開發者逃避思考與設計，最終淪為編碼機器，早早被淘汰。專案不應是「扔給客戶走人」，前人成果後人用不上，說明前人工作不合格。

二、 EJB 與 Spring 的組件化實踐之路

從 COM/CORBA 到 EJB：理想與現實的張力

EJB 出現前，COM 與 CORBA 已嘗試解決分布式組件問題，但未形成完整成熟體系。EJB 承載了業界對組件化的熱切期盼，確實解決了許多問題，但定位高端、技術複雜，導致大量開發者無法掌握，項目失敗頻傳。

.NET 的易用性陷阱

.NET 沿襲 J2EE 思想但降低門檻，RAD 風格明顯，誘使開發者用企業級技術寫高耦合系統，重蹈覆轍。J2EE 強制開發者面對 OOP、分層、解耦、重用，雖「曲高和寡」，但若視程式設計為畢生事業，定能在 Java 世界掌握軟體精髓。

Spring 運動：簡化背後的傳承

Rod Johnson 憑藉多年企業級開發實戰（含 EJB 實踐），創造了 Spring——簡化版的 EJB。關鍵在於「精通 EJB 才能簡化 EJB」。國內許多人捧 Spring 貶 EJB 乃至 Sun，卻忘了 Spring 所傳承的組件化解耦思想。初學者只記簡化，不知根源，這才是危機所在。

Java 界的混亂與堅守

隨後 Java 界陷入「無限簡化」狂歡：簡化到 Web+DB、簡化到 PHP 級高耦合、騎牆式 RoR。組件化面臨危機。值得敬佩的是 Jdon 與 banq，冒天下之大不韪堅持組件化真理，正如英語學習無捷徑，優秀程式設計同樣無捷徑。

三、 堅持組件化，打造真正的軟體工業

軟體危機本質上是產業問題

現代產業皆大分工、大合作的工業化鏈條，分工越細、產業規模越大。軟體業（尤以國內為甚）表面沒事做，實則因低效率導致用不起、不敢用軟體，陷入低水平局部競爭，企業投入產出比低，自然不願投入資訊系統。

分工合作與相互尊重

OS、DB、語言等基礎設施外國已建好，企業級領域仍有無數工作待做。國人缺乏合作精神：精通業務者指揮設計、分析專家挑剔技術、能復用卻重寫以示高明、新手妄想 RAD 搞定一切。「超人意識」害人害己，軟體業太大太複雜，必須分工合作、尊重他人、實事求是。

技術層面的建議

• Spring 已基本解決「解耦」難題，開發者若不偷懶，研讀好代碼，用 Spring 這類「無侵入」框架裝配，可基本解決組件化難題。
• EJB（含 EJB 3） 筆者涉獵淺，待高手指點。
• 每位程式設計師：不偷懶，實踐解耦自身代碼。
• 每家開發商：不急功近利，提煉類庫，互通互聯。
• 系統管理員、CIO、企業領導：拒收高耦合系統、無類庫封裝系統、無測試系統、無類庫文檔系統。

唯有如此，方能杜絕低水平軟體橫行，迎來中國軟體組件化時代，建立健康、有序、高效的軟體產業。