JAVA語言已經慢慢的在成為主流的開發語言之一，或者說現在已經成為了主流的開發語言。在JAVA語言平台上，也出現了多種開發模型。對於剛入門的JAVA程序員來說，也許面對這麼多的開發模型，會眼花缭亂，不知道該如何選擇。筆者剛開始接觸JAVA語言的時候沒有多少的開發模型可以選擇。而前幾年筆者也遇到了這個問題。可選的開發模型比較多，筆者必須選擇一個開發模型作為未來自己的主攻方向。因為人的精力是有限的，特別是我們做程序開發的。我們要把有限的精力花在刀口上。筆者在這裡向大家推薦EJB開發模型。
這個EJB本質上就是一個被管理的組件，存在於J2EE容器中，由J2EE容器進行創建、控制和銷毀。J2EE容器復雜控制當前存在的EJB數目和EJB所使用的資源。在重負載的情況下，即使是客戶端正在使用的EJB，也將被返回到實例池，如此的話，這個EJB實例還可以供其他客戶端使用，從而提高EJB實例的利用率。雖然J2EE官方也是推薦使用EJB，但是這並不是一個強制性的措施。程序開發人員除了利用EJB之外，還可以利用JSP或者單機版的JAVA應用程序等等。但是如果應用程序需要不斷的升級、性能要求比較高等等，那麼筆者就向大家推薦使用EJB，主要有如下三個方面的原因。
一、可以隱藏管道代碼。
現在音樂噴泉在各地迅速的被采用，成為高科技景觀的一個代表之作。程序員在開發這個應用程序的時候，程序人員需要用到這些管道，但是並不需要知道這些水管的具體走向。這不是程序開發人員所需要關注的內容。程序開發人員之需要直接使用這些現成的管道即可。我們把這些管道就叫做“管道代碼”。其實程序開發人員有時候就好像一個工業設計師。工業設計師在設計洗澡用的花撒水籠頭的時候，其根本不用關心自來水管道。為什麼呢?因為自來水管道都是采用同一的標准，水壓的話也是國家有一個強制性的標准。為此在需要使用管道的時候，設計者之需要直接引用這些標准化的參數即可。在早期的一些開發模型中，如最原始的CORBA開發模型，程序開發人員不得不便寫大量的代碼來完成同Corba環境的交互、連接、注冊過程。其實這些代碼就是通常所說的管道代碼。而如果采用EJB模型的話則可以最大限度的減少這些管道代碼的編寫工作。
如程序開發人員通過聲明屬性就可以無需要編寫代碼來控制這些功能即可指定組件的事務性為;不用通過編寫管道代碼來定義EJB組件之間的關系以及所需要用到的資源，因為可部署的J2EE應用程序在部署描述信息中定義了多個EJB組件之間的關系同時定義了EJB組件所需要用到的資源;如每個Bean都遵循一個定義的聲明周期和一套規則，為此程序開發人員不需要知道“管道”的設計，而只需要知道管道接口的參數即可，如此的話系統代碼與應用程序代碼之間就是兩個互相獨立的內容。
顯然，通過J2EE提供的EJB組件，可以讓程序開發人員將精力集中在業務代碼的編寫上，而盡量減少編寫管道代碼。這不僅可以提高應用程序的開發效率，而且把管道代碼與應用程序代碼獨立開來，也利於後續的調試與維護。這就是筆者推薦使用EJB模型來開發JAVA應用程序的第一個原因。
二、EJB預定義了一些復雜的處理機制。
在應用程序開發的過程中，或多或少有一些共性的內容。如需要進行應用程序的生命周期管理，需要進行命名和注冊，需要進行事務管理等等。如果每次在開發應用程序的時候，都需要從零開始來開發這些功能，那麼工作量就會很大，而且代碼的重復利用性也會比較差。為了解決這些問題，EJB提供了一些預定義的服務，把一些應用程序開發中要用到的服務集成到J2EE開發環境中。需要用到這些服務的時候，程序開發人員之需要聲明一下或者通過少量的代碼就可以調用這些服務，實現一些復雜的控制管理機制。
如在應用程序開發中，為了保持數據的一致性事務管理機制是必須要實現的一個機制。如果在應用程序層面沒有實現事務管理機制的話，則當同一個業務涉及到多條記錄的時候，很容易破壞數據的一致性。而如果從零開始來編寫事務處理機制代碼的話，那麼工作量會很大。在EJB的容器服務中就預先提供了事務管理的解決方式，程序開發人員可以憑借這個預定義地解決方案輕松的創建事務、處理與控制事務等等。
如在應用程序開發中命名與注冊也是很麻煩的一件工作。而EJB也提供另一個命名與注冊的容器，EJB容器和服務器為EJB提供了對命名服務的訪問。遠程和本地客戶端使用這些服務來尋找EJB;EJB組件本身也使用這些服務來查詢自身所需要的資源。也就好說，程序開發人員在應用程序開發中不用通過代碼來實現命名與注冊服務，而直接調用EJB組件中的命名與注冊容器即可。這個容器會自動生成相關的代碼來完成所需要實現的功能。
另外，EJB組件還提供了生命周期管理容器、安全性和訪問控制容器、持久性容器等等，通過這些容器可以讓程序開發人員少寫大量的代碼，不僅可以提高程序的開發效率，而且同意了這些基礎性內容解決方案。這也有利於後來的人員了解源代碼，有利於應用管理軟件的後續升級。
三、用戶接口與底層業務功隔離。
在企業管理中共性與個性是並存的，這也體現在了企業的管理軟件上。如同一家企業，如果管理者的文化背景不同，其或許多同一個業務具有不同的管理方式。這個用我們程序開發人員專業的術語來講就是用戶接口不同。但是其背後的管理模型是相同的，也就是說其業務功能是相同的。如利用JAVA語言開發的一個訂單管理系統，其訂單的處理機制是相同的，都在數據庫中建立相關的紀錄並在保存記錄之前進行數據有效性的審核。但是不同的訂單類型其處理方式可能稍有不同。如對於預付訂單，必須要先收到客戶的款項才能夠下訂單給生產部門安排生產或者倉庫部門准備出貨;如對於倉庫訂單，則在流程處理上不需要經過生產而直接轉到倉庫出貨等等。也就說是，10種不同類型的訂單，其80%的功能是相同的，而又20%的內容由於管理方式或者其他的原因而有所不同。在這種情況下難道要寫十個不同的代碼來實現這十種不同的需求嗎?
在EJB開發模型中不用這麼復雜，因為EJB允許獨立於表達層開發和部署業務功能。如上面這個訂單管理需求，程序開發人員可以利用EJB模型來實現底層的功能(80%的共性內容)，然後再無需重新設計或者開發整個應用程序或者銷售訂單管理模塊的情況下，可以利用不同的用戶接口來實現用戶的不同需求。這就好像父母與子女的關系。現把父母的特性定義好，然後再根據不同的需要生養不同的子女即可(用戶接口)。由於子女繼承了父母的全部特性。那麼只需要把用戶需要實現的一些個性特點嫁接到子女身上即可。所以這種業務需求與業務功能相分離，各自獨立的特征，是EJB開發模型的最大優勢。程序開發人員可以利用EJB實現分布式應用程序，將用戶接口與底層業務功能隔離開來。
