取得領先
VMware 提供培訓和認證,以加速您的進展。
瞭解更多職位列表是衡量技術真正普及程度的良好指標。它們顯示公司是否正在花錢,從而可以區分實質與炒作;它們表明開發人員獲得和培養相關技能的重要性(技術延續的一個重要因素);它們為公司採用特定技術提供了良好的安全指南。
因此,Indeed.com 的 jobtrends 網站(一個職位列表聚合網站)是一個重要的資源。它允許追蹤職位要求數量隨時間變化的趨勢,並方便比較各種技術。
有時這些趨勢可能會產生巨大的影響。Indeed.com 顯示,在 2007 年 11 月,Spring 取代 EJB 成為 Java 職位列表中對技能的要求。 截至昨天,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 中的許多缺陷,例如啟動操作、單例和過時的執行緒模型。 最後,它有效地與應用程式伺服器環境綁定,而此時基礎架構正在發生變化。
我可以繼續談論這些缺陷,但職位數量說明了成千上萬家公司的實踐經驗和結論。
請注意,我這裡談論的是 Session Bean 和 Message Bean;JPA 現在是一個單獨的規範,基於現代技術,並且正在證明其價值。
EJB 的衰落對整個行業以及個別開發人員意味著什麼?
坦率地說,EJB 時代是一種反常現象。 EJB 未能解決本世紀初的問題;它仍然不足以應對未來的問題。 EJB 的大多數初始前提現在都被否定了;該規範對向後相容性的堅持並不能證明它所帶來的權衡是合理的。 它的衰落是進入一個新的、更流動的世界的自然結果,在這個世界中,諸如 OSGi 和不起眼的 Servlet API 等技術證明了它們更具相關性。 當然,由於絕對數量仍然很高,EJB 不會在短期內完全消失。 但趨勢線清楚地表明它 正在 成為舊有技術。
恰逢其時的是,職位要求方面的這一里程碑恰好發生在我們宣布 SpringSource Spring 認證計畫之前。 既然 Spring 在市場上是一項如此重要的技能,那麼對雇主和開發人員來說,擁有一個對 Spring 知識的明確衡量標準非常重要。
最近,2007 年領先的行業網站上的統計資料進一步證明了 Spring 的發展勢頭。在 ServerSide 上,前 5 名文章中的 2 篇是關於 Spring 的,包括排名第一的文章。在 InfoQ 上,前 10 名中有 3 篇是關於 Spring 的,其中排名第一的文章(我的 Spring 2.0 更新)的頁面瀏覽量是下一篇最受歡迎的文章的 4 倍。