delvin

EJB儼然成為了一個任人打扮的小姑娘。現在你只要和一個國內Java開發人員交流，基本都能聽到他們說EJB的缺點，即使他沒有使用過。
為此我花了點時間，試圖分析下EJB的優點和缺點，以及EJB對Java技術社區的貢獻。

我使用了EJB有6年時間，從接觸Java就開始學習EJB,使用過EJB1，EJB2和EJB3。

我總結的EJB(EJB1和EJB2)存在的問題有：

目標定位不清
編成模型復雜
開發和移植困難
部署描述符陷阱
類加載陷阱
測試困難
破壞面向對象設計
部署慢
運行時需要EJB容器，代價高
維護困難
學習曲線大

下面我們逐一分析
一 目標定位不清
假如你看過EJB早期規范，你會發現，規范中隊EJB的目標定位有11項之多。為了分析方便，我引用了EJB2.1版本中有關EJB目標定義的內容（注：序號是我加上的）。
The Enterprise JavaBeans (EJB) architecture has the following goals:
 1）The Enterprise JavaBeans architecture will be the standard component architecture for build-
ing distributed object-oriented business applications in the Java programming language.
 2）The Enterprise JavaBeans architecture will support the development, deployment, and use of
web services.
3）The Enterprise JavaBeans architecture will make it easy to write applications: Application
developers will not have to understand low-level transaction and state management details,
multi-threading, connection pooling, or other complex low-level APIs.
4） Enterprise JavaBeans applications will follow the Write Once, Run Anywhere? philosophy of
the Java programming language. An enterprise bean can be developed once, and then
deployed on multiple platforms without recompilation or source code modi?cation.
5） The Enterprise JavaBeans architecture will address the development, deployment, and runtime
aspects of an enterprise application’s life cycle.
6） The Enterprise JavaBeans architecture will define the contracts that enable tools from multiple
vendors to develop and deploy components that can interoperate at runtime.
7）The Enterprise JavaBeans architecture will make it possible to build applications by combin-
ing components developed using tools from different vendors.
8） The Enterprise JavaBeans architecture will provide interoperability between enterprise beans
and Java 2 Platform, Enterprise Edition (J2EE) components as well as non-Java programming
language applications.
9） The Enterprise JavaBeans architecture will be compatible with existing server platforms. Ven-
dors will be able to extend their existing products to support Enterprise JavaBeans.
10） The Enterprise JavaBeans architecture will be compatible with other Java programming lan-
guage APIs.
11）The Enterprise JavaBeans architecture will be compatible with the CORBA protocols

從這些目標中我們可以發現，幾乎沒有目標是針對開發人員效率的。從這次目標中我們就可以隱約的感到EJB不是對開發者友好的技術。
從這些目標中，我們可以發現EJB的雄心過于龐大，而EJB出現的時代，還不足以在一個規范中解決這些問題。從EJB后來被人詬病最多的實體Bean，只是EJB的一小部分，但恰恰就這點就要了EJB的命。

EJB目標中把本不應該放在一起的東西給放在了一起，比如分布式和實體映射。而且錯誤的假定了使用分布式的場合。按照Spring創始人的說法
，分布式只有20%的應用要用，而80%是不需要的。
我們現在知道EJB目標不清楚，那我們免不了要問，當初Sun為什么要這樣定位EJB？
也許除了EJB早期規范組的人，沒有人真正清楚為什么，我們此處只能留到以后事后諸葛亮下（注：此處我以后會用一片文章來分析產生的原因）。

二 編成模型復雜

EJB組成復雜：
 一個EJB有好幾個東西組成，具體有主接口 ，遠程/本地接口，Bean類，部署描述符
雖然開發社區發展了Xdoclet技術，但也只是解決了一部分問題。用Xdoclet，編譯時需要產生代碼，當EJB多時，這是很耗時的。

有過開發經驗的人都知道要是修改一個小東西需要修改幾個文件的話，那工作效率是上不去的，另外在考慮到EJB的需要部署，啟動服務器的時間，修改EJB簡直是痛苦啊。這樣必然導致開發周期長。
  編寫（定義接口，  實現Bean， 編寫部署描述符）-》打包部署-》     啟動服務器-》測試。

早期開發中，我們還遵守規范中按角色編程的要求，導致角色多，溝通成本高，比如Bean開發者開發Bean，部署員打包部署，系統管理者管理服務器。

三 移植困難（特別是Entity Bean）
規范中說的編寫一次，到處部署的承諾，基本是一句空話。結果變成了編寫一次，到處重寫。特別是實體Bean，基本上遷移一個服務器，就相當于用HIbernate重新的工作量，還不考慮測試的困難性。規范中對實體映射定義的太過于寬泛，導致每個廠商都需要自己的ORM實現，引入 特定廠商的部署描述符，又因為J2EE中除web外，類加載的定義沒有明確，導致產生特定廠商的類加載機制和打包方式，還有就是特定廠商的服務查找方式。

四 部署描述符陷阱
 1）EJB采用了當時流行的使用Xml作為粘合劑，并且實現廠商都引入了自己的配置文件。結果導致編寫過多的配置文件。以JBoss為例要寫要寫三個配置文件。XML配置文件復雜，手工編寫比較困難，早期IDE中可視化編寫XML效率有不高，導致開發人員開發效率大大降低。更痛苦的是修改后，不能及時生效。大家想象一下，如果你有多個EJB，修改一個需要重新部署和啟動服務器，那是怎樣的浪費時間。以我曾經的一個項目為例，約有100個EJB，部署和重啟JBoss需要幾分鐘，重要不是浪費時間，而是那種挫折感。
 2）標準的ejb-jar.xml部署描述符把一些重要的信息（比如指定EJB的JNDI名字和配置實例池）都留給容器提供商，
我們一般都需要一個額外，特定于容器的的部署描述符，比如weblogic-ejb-jar.xml。這樣導致編寫和移植的困難。

五 類加載陷阱（類加載器復雜，并且不清晰）

J2EE規范（Java EE）對EAR中web和ejb的加載沒有明確定義。比如一個EAR有多個EJB，每個EJB都依賴一些其他類庫，那么對這些被依賴的類庫到底是怎么被加載的，類的可見性怎么樣，規范沒有規定。這樣每個廠商都有自己的一套東西，導致不同服務上，要用不同的打包方式。

六   測試困難
J2EE測試難是有目共睹的，其中EJB測試困難時出了名的。測試困難的原因時，EJB運行需要容器插入什么服務，而啟動服務器是很高昂的代價。
后來雖然開發社區采用Mock等技術試圖解決這個問題，但從開發實踐來說，還是有難度的。

注: 以下幾點問題，還需要詳細分析，由于時間問題，暫時只是列出來。
七   破壞面向對象設計
八  開發周期長，部署慢
九  運行時需要EJB容器，代價高
十  維護困難

但說實話EJB也是有貢獻，當然它的貢獻更多是理念層次，在實現層面很失敗。另外，也正是他的失誤，在批判EJB的基礎上發展起Spring，給開發人員帶來一股新風。