企業級JavaBeans（EJB）是J2EE平台中最復雜的技術之一，因此一些開發人員不願意在他們的項目中部署EJB.
本文面向那些仍舊對是否投入時間和精力學習並在他們的項目中部署EJB技術持觀望態度的開發人員。首先，我們介紹了EJB的優點和缺點，然後，說明了何時你可能需要或不需要使用EJB.
最後通過說明我對EJB錯誤觀念一些看法得出結論。
優點
規范：EJB是一項技術規范的技術。（這既是EJB的主要優點也是一個主要缺點。）EJB規范幾乎描述了實現的所有方面，包括數據類型，組件生命周期，角色分配以及很多其它方面。
與J2EE緊密結合：J2EE平台中有一組完整的服務器技術，包括EJB和其它非常有價值的技術諸如servlets，JavaServer頁，Java消息服務，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的主要目標和缺陷。
