為什么我喜歡EJB 3.0并且尤其喜歡EJB 3.1
Marc Fleury在2002年寫了一篇值得一讀的文章 藍皮書 "為什么我愛EJB" (下載),他的觀點在當時是令人驚訝的。我那是已經在使用EJB,但并不真正地愛他們 :-)。我沒有到哪個程度,但我真的喜歡EJB 3.0。原因如下:
◆性能開銷低。Glassfish v2中 只有大約3%.
◆EJB 3.0是線程安全的(thread save)。這是一個巨大的優點。 每個線程所都擁有的實例,包括所有注入的資源比如實體管理器(Entity Manager),數據源(Data Source)和JMS,都是線程安全的。最棒的是:容器為你做到了這一切。你只需要一個標識(annotation),比如引用EJB的@EJB,獲取持久化上下文的@PersistenceContext以及引用資源的@Resource :-))。更多討論請參看"plain old Web Container" :-)(想想POJO-Plain Old Java Object,譯者注)。提醒一下:Servlet作為一種單例(singletons)模式不是線程安全的。
◆EJB 3.0 支持 事務(transactional)。 所以只要成功調用了EJB方法,所有的資源將都是同步的(synchronized),比如寫到數據庫中的數據,發給服務器的消息等。容器會為你做到這些,你只要知道你所要做的是什么 (這和平臺無關,但有時難以實現 :-))
在我所有的項目中都將部署描述符而替換成了annotation。這樣就只有一個persistence.xml文件需要部署。EJB在重構,部署和移植方面都表現良好。
◆EJB 3.0是真正可移植的(它可以讓你中立于實現提供商和架構)。 相比EJB 2.1,這點更加突出,因為私有的部署描述符不再需要。實際上,EJB 3不再需要任何描述符。你只要部署干干凈凈的jar文件,然后附上在meta-inf中的persistence.xml,而其他都是可選的。
◆在EJB 3 中,慣例優先原則(Convention Over Configuration)或正式地稱為基于期望的配置( Configuration By Exception) ,它們和依賴注入(Dependency Injection) 的結合非常完美。大多數場合,開發EJB只需要少量的代碼(比如沒有"new"的調用,而只需要做個聲明)
@Stateless |
◆Getters 和Setters方法是可選的: 不僅對于EJB,同樣對于JPA。 資源可以直接注入到字段之中。
缺省和annotation的配置能夠被XML描述符覆蓋。而XML描述符不需面面俱到 - 你只要指定感興趣的部分。你可以為某個特定階段(比如測試、集成)開發通過XML描述對產品進行重新設置。
◆不需要特別的工具。你只需要annotation,一個Java 6 的編輯器和一個Jar文件。 無論是IntelliJ,Eclipse (含500附件的插件:-))還是Netbeans 6.1都對EJB 3提供了完善的支持,并對應用服務器也做了很好的集成,EJB的部署、取消部署、配置等都可以直接由IDE來管理。
◆EJB 3.1可嵌入的特性很可能將獲得支持。Glassfish v3已經對此提供支持。在GlassFish的測試中,我發現容器的啟動只要令人驚訝的500ms。 此外,JBoss也支持可嵌入。
◆EJB 3.1將提供許多有用的特性:Singletons (更便于配置和用于啟動類等), 更好的timer支持 (cron-like),將來的異步方法,可選的local-interfaces 和基于WAR包的部署。
◆池的設置和線程池的配置對伸縮性的控制非常有幫助(除非容器崩潰,否則你不會為無法確定伸縮性而頭痛:-))
◆和腳本語言交互的良好支持(包括JavaScript, Groovy)
◆EJB是缺省可以被管理和監控的。EJB部署到容器后,你就可以對其方法調用和性能等進行監控。
◆不需事先依賴任何的架構和庫等。ejb-jar和容器為你的應用代碼打理一切,所以拋出像NoClassDefFoundErrors,ClassCastExceptions這樣異常的可能會降到最低。
◆EJB 3.0是超級緊湊的技術。實際上你已經不可能再為它做些什么簡化 :-)。當然,這方面我也愿意聽大家的意見。
◆他們非常容易測試-因為EJB就是一些類和接口。你甚至可以在容器之外啟動它們。
◆即使最簡單的use cases也可以用EJB 3高效的實現。比如關于增刪查改的 CRUD的例子:
@Stateless |
◆他們工作的非常棒:近兩年來,我在項目中使用EJB 3.0 + JPA 1.0。它們的出色表現不僅給我帶來的驚喜,也給我們團隊的帶來了驚喜。
然而,Java EE6平臺仍有可以提升的空間。JMS規范應該重新設計,讓其更加“流暢”(fluent)。JNDI注冊機制顯得陳舊,有關JNDI的API的改進和簡化將不僅有助于EJB的開發,而且整個Java EE平臺也將因此受惠。
【編輯推薦】