領先一步
VMware 提供培訓和認證,助您加速進步。
瞭解更多職位列表是技術真正普及情況的良好指標。它們表明公司是否在花錢,從而區分實質與炒作;它們表明開發人員掌握和發展相關技能的重要性(技術延續的一個重要因素);它們還可以為公司採納特定技術的可行性提供良好指導。
因此,職位列表聚合網站 Indeed.com 的 jobtrends 網站是一個重要資源。它允許跟蹤職位要求數量隨時間的變化趨勢,並方便地比較技術。
有時這些趨勢會帶來巨大的影響。Indeed.com 顯示,在 2007 年 11 月,Spring 在 Java 職位列表中的技能要求超越了 EJB。截至昨天,Spring 的職位數量為 5710 個,而 EJB 為 5030 個。
透過比較絕對職位數量,我們可以看到趨勢線以及它們何時交叉
考慮到大量的遺留 EJB,這真是令人驚訝。推測起來,現在很少有新專案使用 EJB 了。
“相對”圖表,比較各自的增長率,則更有趣,它顯示了這兩種技術之間鮮明的對比
我們看到 EJB 的需求停滯不前或呈下降趨勢,而 Spring 的需求正以不斷增長的速度增長。
當然,Spring 和 EJB 並非互斥。使用 Spring 並不會阻止您使用 EJB,反之亦然。在某些情況下,EJB 可以提供您可能想要在中使用 Spring 的應用程式中有用的服務。在沒有 Spring 的情況下使用任何版本的 EJB 都將放棄眾多寶貴的附加功能。事實上,正是支援 EJB 的遊說團體(無論出於何種原因)將這兩種技術描繪成直接的競爭對手。
這兩種技術之間的重疊非常顯著且在增長,但其增長速度不及 Spring 需求增長的速度
儘管這不是一個蘋果對蘋果的比較,但將 Spring 和 EJB 視為企業 Java 應用程式核心元件模型的替代方案是合理的。而且,很明顯哪一個現在處於上升趨勢。
我必須承認,我個人有一些滿足感,因為我從 2003 年初就開始預測 EJB 將會過時,並且在此之前就認為 EJB 被過度使用了。在《J2EE without EJB》一書中,我詳細分析了 EJB 模型的缺陷,以及它未能達到其既定目標或滿足開發人員和客戶需求的原因。當時,這些說法非常有爭議。
EJB 3.0 在某些方面有所改進,但為時已晚:DI 功能不如實際世界所需的充分;攔截 API 認識到需要解決橫切關注點的問題,但提供了迄今為止最不強大、最笨拙且最容易出錯的解決方案(這一點我一直想寫篇博文);它揹負著與現在無關的上一代技術的向後相容性的包袱;完整的 EJB 契約(比“簡化的程式設計模型”長數百頁)規定了一個具有過度開銷的複雜執行時;儘管有語法糖,但它未能解決 EJB 中的一些缺陷,例如啟動操作、單例和過時的執行緒模型。最後,它實際上被繫結到應用程式伺服器環境,而此時基礎設施正在發生變化。
我可以滔滔不絕地談論這些缺陷,但職位數量則說明了成千上萬公司的實際經驗和結論。
請注意,我這裡說的是會話 Bean 和訊息 Bean;JPA 現在是一個單獨的規範,基於現代技術,並且正在證明其價值。
EJB 的衰落對整個行業以及個體開發者意味著什麼?
坦率地說,EJB 時代是一個異常。EJB 未能解決本世紀初的問題;對於未來的問題,它仍然不足。EJB 最初的大部分前提現在已經失效;該規範堅持向後相容性並不能證明它所帶來的權衡是合理的。它的衰落是向一個更靈活的新世界發展的自然結果,在這個世界裡,像 OSGi 和樸實的 Servlet API 這樣的技術被證明更加相關。當然,由於絕對數字仍然很高,EJB 不會很快完全消失。但趨勢線清楚地表明,它確實正在成為遺留技術。
這個在職位要求上的里程碑恰好發生在我們在宣佈 SpringSource Spring 認證計劃之前,這很及時。現在 Spring 是市場上的一項重要技能,對僱主和開發人員來說,有一個明確的 Spring 知識衡量標準非常重要。
Spring 動力的進一步證明最近得到了 2007 年領先行業網站的統計資料。在 ServerSide 上,排名前 5 的文章中有 2 篇是關於 Spring 的,包括頭條文章。在 InfoQ 上,排名前 10 的文章中有 3 篇是關於 Spring 的,頭條文章(我的 Spring 2.0 更新)的頁面瀏覽量是下一篇最受歡迎文章的 4 倍。