EJB 3.0是Hibernate的複製嗎?

來源:互聯網
上載者:User
   摘要 Sun的EJB 3.0規範正處於其最後的"衝刺"階段,許多公司都在為遵循這一規範而忙碌著。這個EJB規範最新版本所提供的眾多優點中比較突出的當屬其資料庫功能,但是一些開發人員感到,這個規範僅僅是Hibernate持久性儲存引擎的一個"複製"版。真的嗎?本文正是想討論這一問題。

  實踐證明,Hibernate是針對於Java語言所建立的最優秀的持久化儲存引擎之一。至今,我還清晰地記得第一次使用Hibernate工作的情景。當時,我們已經有了一種現成的持久化儲存引擎,但是這個引擎將消耗大量的系統資源並且從未真正正確工作過。令人驚奇的是,Hibernate"瞬間"解決了我們的持久化儲存問題!這真是一個"天賜之物"。不覺間,時間快速推進到今天。EJB 3.0又浮出水面,並且不久我們就要計劃把我們當前的EJB 2.x伺服器向這個更高版本升級了。然而,仔細地分析一下EJB 3.0中所作的持久性儲存變化,有人可能會感到驚訝-這不是來自於Hibernate的一個"複製"品嗎?難道Sun當真"偷竊"了來自於Hibernate的設計嗎?我的回答是,情況要比這些複雜得多。

   一、 EJB 3.0

  EJB 3.0必須實現的重要目標之一是,要使之成為更為有用和更便於使用的開發工具。Sun公司的Linda DeMichiel認識到,為了成功實現這一目標,EJB 3.0必須要基於開發人員今天正在使用的現有庫;否則,它將會導致一種困難的升級操作並且可能會引不起足夠的重視。因此,來自於Oracle,JBoss,Apache,BEA,Novell,Google的成員和其它方面的專家都被邀請參與制訂這一規範。這個小組的目標是,生產一種規範-能夠使得EJB更易於開發並且還要建立一種便於開發人員能夠容易地實現升級的持久性儲存標準。

  當這個小組開始開發EJB 3.0規範時,他們很快認識到,其中很多特徵應該在功能上與所有的主要的供應商和庫保持一致。我們將在下面的幾節中討論這些特徵。

  (一) EntityManager

  這個EntityManager負責處理一個事務。在JDO中,它被稱作持久性儲存管理器,而在Hibernate中稱它為一個會話。在GlassFish工程中,EntityManager被作如下描述:

  其實,一個EntityManager執行個體與一個持久性儲存上下文相關聯。一個持久性儲存上下文是一組實體執行個體,其中的任何一個持久性實體都是唯一的一個實體執行個體。在該持久性儲存上下文中,實體執行個體及其生命週期都是可被管理的。這個介面定義了用於與持久性儲存上下文進行互動的方法。EntityManager API用於建立和刪除持久性實體執行個體-通過其主鍵尋找實體和查詢實體。

  這個可由一個給定的EntityManager執行個體管理的實體集合是通過一個持久性儲存單元進行定義的。一個持久性儲存單元定義了所有類的集合,這些類是相聯絡的或由應用程式加以分組,並且它們必須共存於它們到單個資料庫的映射中。

  (二) 命名查詢

  一個命名查詢是一個預定義的查詢,它被賦予一個名字,這樣它可以在以後通過該名字加以存取。用資料庫術語來說,命名查詢被稱作預存程序。當結合本機查詢時(見下一節),資料庫查詢應該是非常輕鬆的。

  (三) 本機查詢

  不是使用具有很多限制性的實體查詢語言,本機查詢允許直接從EJB中全面地使用SQL語言。現在,我們有可能直接在資料庫上調用count(),max()和其它功能而不必付出其它周折。

  (四) 回調監聽器

  回調監聽器,是一種事件監聽器,或用資料庫術語來說是,是一種觸發器。它們支援當一個事件發生時進行代碼調用。

  (五) 脫離/重新依附對象

  能夠脫離開一個EntityManager的控制範圍而又能夠重新返回而被持續化儲存,這在EJB 3.0版本之前是無法實現的。在以前,為了實現這一目的,必須把來自於一個對象的值必須被複製到一個POJO(普通Java對象)中,然後被再往回複製。

  在EJB 3.0之前,我總是使用值-對象並且把來自於EJB的值複製到一個POJO中;然後,使用在前端使用該對象。如果該POJO中的一個值被改變,它將不得不被"推回"到該EJB;然後,該值被複製回來。這種"混亂"狀態現在已經不複存在了。一個對象甚至能夠完全離開JVM並且在以後某個時期返回回來並且被重新依附。這種改變所帶來的效率是不能被低估的。

  (六) O/R映射類型

  能夠把一個EJB中的欄位直接映射到一個資料庫中的列上是EJB 3.0以前也是很難實現的。這一功能實現一直不那麼令人滿意,並且很多第三方開發工具都一再延遲對這種功能的支援。我最喜歡的xDoclet的一個特徵是,它能夠定義在我的EJB中每一個持久性欄位對應哪種SQL類型。藉助於EJB 3.0和註解技術,我們不再需要使用一種第三方工具。

   二、 EJB 3.0對象

  值得注意的是,企業Java Bean現在被稱為POJO。隨著註解技術的出現,java bean不再需要介面、home和描述符支援檔案。僅僅這個特徵就為EJB 3.0贏得了大批Team Dev的青睞。

  現在,既然企業對象不再被鎖定到應用程式伺服器內,那麼我們不再需要把它們複製進和複製出POJO,這樣就允許不必把應用程式伺服器後端和前端區別得那麼嚴格,從而使開發人員能夠更容易地顯示和編輯儲存於EJB中的資料。我們很快就會看到這些變化對xDoclet所產生的有趣影響。

   三、 結論

  儘管毫無疑問,EJB 3.0基於Hibernate,但是,事實上它是基於所有的頂級的對象/關係映射工具。看來,這個工具並非這些工具簡單"修改"版,而事實上是由Sun創造的又一部傑出的"電影"。不必讓開發人員學習一種"全新的但還是功能相同的工具",開發人員只需要輕鬆地花一些時間就可以升級到新版的EJB 3.0中,因為EJB 3.0正是基於他們已經瞭解和喜歡的工具建立的。

相關文章

Beyond APAC's No.1 Cloud

19.6% IaaS Market Share in Asia Pacific - Gartner IT Service report, 2018

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。