用企業級JavaBeans前需要考慮幾個因素

來源:互聯網
上載者:User

企業級JavaBeans(EJB)是J2EE平台中最複雜的技術之一,因此一些開發人員不願意在他們的項目中部署EJB。

本文面向那些仍舊對是否投入時間和精力學習並在他們的項目中部署EJB技術持觀望態度的開發人員。首先,我們介紹了EJB的優點和缺點,然後,說明了何時你可能需要或不需要使用EJB。

最後通過說明我對EJB錯誤觀念一些看法得出結論。

優點

規範:EJB是一項技術規範的技術。(這既是EJB的主要優點也是一個主要缺點。)EJB規範幾乎描述了實現的所有方面,包括資料類型,組件生命週期,角色指派以及很多其它方面。

與J2EE緊密結合:J2EE平台中有一組完整的伺服器技術,包括EJB和其它非常有價值的技術諸如servlets,JavaServer頁,JavaMessage Service,J2EE連接器體繫結構,Java資料庫連接,Java認證與授權服務,Java事務API和JavaMail等。這使得J2EE和EJB成為一個很有吸引力的解決方案。

可升級性:只要你將大部分資源管理函數傳到應用伺服器,供應商就可以運用複雜的升級演算法。

可訪問資源管理系統:利用EJB容器,你可以獲得成千上萬行的代碼來訪問和管理資源,包括交易管理系統,安全管理系統和目錄服務。沒有EJB的話,你只能自己實現這些組件。

缺點

大量複雜的規範:對於描述一個複雜分布式系統的規範來說這是很正常的,但是並不是裡面的所有資訊都需要編碼,這使得規範成為一個很不方便的工具。

龐大的文檔:在開始開發一個項目之前,你通常需要閱讀1000多頁的文檔,這是部署EJB的很令人畏懼的原因之一。

增加了開發時間:EJB解決方案比普通Java代碼實現要求更多的時間。調試EJB代碼需要的時間也要比調試普通Java代碼長。主要原因是因為你不能確定漏洞是在你的代碼中還是在容器中。

EJB代碼更複雜:例如,為了實現一個會話bean,你必須編寫三個類,一個登入bean,你必須編寫四個類。添加一兩個部署描述符和一個最簡單的“Hello world”應用就會產生10個檔案而不是一個檔案。

重複設計的危險:這是規範複雜性的後果。如果你沒有很好的理解EJB的概念,你就不能有效地使用該技術,而且你還可能把項目變得比實際需要的更複雜。

規範改變:EJB是一項新興技術,你的代碼潛在地存在過時的風險,這就要求增加額外的工作和投入來使得它與新的EJB容器相容。

什麼時候你可能想要使用EJB

假設你有一個使用資料庫的簡單servlet Web應用。你使用JDBC從你的應用訪問資料庫。作為一個SQL查詢的結果,你會得到擁有一些資料的結果集ResultSet,這些資料代表了你的業務對象。

這種方法使用資料不是很方便。你需要建立一個Java類表示一個資料庫結構,你的代碼可能如下所示:

MyObjectobj = new MyObject();

obj.setXXX(rs.getString("XXX"));

obj.setYYY(rs.getString("YYY"));

在將結果集換成對象表示與返回後,你需要考慮如何將這個邏輯轉移到MyObject中。為了將servlet從JDBC訪問細節中分離出來以及不在直接使用java.sql.*包中的類,你應該讓該對象可以在資料庫中找到自己,然後修改或刪除它。

現在又有另外一個問題:如何通過某些查詢找到資料庫中的一個對象?如果你需要通過主鍵找到它,那麼你需要將主鍵傳給類建構函式即可。如果你需要通過某些準則尋找,這將需要很多專用靜態方法。如果需要的話,你可能還需要支援交易處理和滾回的方法。

當你的應用程式獲得廣泛應用時,正常已耗用時間百分比和可用性將變得十分重要,這時你會需要複製,快速對象持久性,對象高速緩衝區,資料庫連接池,安全事務等等。

所有這些問題都可以由實體企業級Java Beans解決。你不會再犯許多程式員已經犯過的錯誤。如果你的bean是一個容器管理持久性bean,那麼你只需要實現一兩個介面,而不必考慮必須訪問的資料庫。如果不能完全滿足你的需要,也沒有問題,你可以使用Bean 管理持久性(BMP)實體自己實現持久性。

在你的應用程式業務域中,對象不僅儲存資料,還有一些行為。這些行為代表商務邏輯。當你開始編寫應用時,所有商務邏輯都存放在servlet中,所以你的應用需要一些servlets的支援。

你可以選擇是複製粘貼商務邏輯代碼,還是將它放在獨立的類中。最後,可能有些使用者要求在不同的Web頁面中與你的應用進行互動,你需要儲存每個使用者請求之間的會話資訊。解決這個問題的方法稱為會話Bean,它封裝了你的應用中的所有商務邏輯,它可以是有狀態的或是無狀態的。

什麼時候你可能不想選擇EJB

EJB確實是一項很好的技術,但是它並不是一個通用解決方案。EJB提供的很多特性(像安全性、持久性和事務支援)並不是每個應用都需要。

此外,在非分布式應用中你也可能不想使用EJB,因為這種程式速度可能比安全和交易處理更重要。由於EJB的分布式本質,為了便於在用戶端和EJB組件(或伺服器)之間進行通訊,資料必須先進行某種處理(序列化)然後再進行反處理(串列資料並行化)。這導致了大量的開銷,使得效能下降,這也是為什麼使用JVM(Java虛擬機器)中的本地類可能更好些的原因。

關於EJB的幾種錯誤觀念

EJB是一項昂貴的技術:這種說法部分正確。但最近已經發布了幾個低價位或免費的應用服務,這些應用服務具有商務服務器的所有功能。在一個大型公司專屬應用程式項目中,應用伺服器的花費只是整個項目開銷中很小的一部分。

如果使用CMP beans,你就不需要SQL相關知識:這是不正確的。

EJB應用便於在不同的容器之間移植:這種觀點部分正確。EJB代碼只有在以可移植的方式編寫時才能移植。會話beans和BMP beans可以很容易的移植,但是移植CMP beans需要大量的工作。

實體beans工作速度緩慢:基本上是正確的。實體beans確實運行很慢,而且很多情況下,最好將它們轉換成會話beans。

結論

對於你的項目在做出是否使用EJB技術決定之前,你需要理解你的應用的所有需求,它的演化前景以及EJB的主要目標和缺陷。



相關文章

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 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。