設計模式在EJB中的應用(下)

2019-11-18 12:17:44

字體：大中小

來源：轉載

供稿：網友

　　Factory模式和Singleton模式
　　
　　該模式類似new，是用來創建對象的，使用Factory模式是為了實現面向對象的基本原則.封裝(Encapsulation)和分派(Delegation);將創建對象與使用對象進行分工。因此在平時開發過程中，盡量使用Factory模式創建對象。
　　
　　本例CatalogEJB中是使用Factory模式獲得一個DAO的具體實例對象，見上面CatalogEJB代碼中注釋。我們看看CatalogDAOFactory的代碼:
　　
　　public class CatalogDAOFactory {
　　public static CatalogDAO getDAO() throws CatalogDAOSysException {
　　
　　　　CatalogDAO catDao = null;
　　　　try {
　　　　　　InitialContext ic = new InitialContext();
　　　　　　String className = (String) ic.lookup(JNDINames.CATALOG_DAO_CLASS);
　　　　　　catDao = (CatalogDAO) Class.forName(className).newInstance();
　　　　} catch (NamingException ne) {
　　　　　　...
　　
　　　　}
　　　　return catDao;
　　}
　　
　　
　　在CatalogDAOFactory可以依據系統的配置文件，動態獲得DAO的方法，之所以采取動態方式，當然便于用戶自己增加自己的DAO方式，而不必修改代碼，只要直接修改配置文件就可以。
　　
　　假如在這里只需要CatalogDAOFactory產生一個實例,可以采取Singleton模式,Singleton的目的是控制類實例對象的創建，并且答應整個程序只在一點對它進行訪問。Singleton本身類只能創建一個,是單線程。
　　
　　
　　public class CatalogDAOFactory {
　　PRivate static CatalogDAO catDao = null;
　　
　　public static CatalogDAO getIntance(){
　　　　if (catDao==null)
　　　　　　try {
　　　　　　　　InitialContext ic = new InitialContext();
　　　　　　　　String className =
　　　　　　　　　　(String) ic.lookup(JNDINames.CATALOG_DAO_CLASS);
　　　　　　　　catDao = (CatalogDAO) Class.forName(className).newInstance();
　　　　　　} catch (NamingException ne) {
　　　　　　　　...
　　
　　　　　　}
　　　　 }
　　　　return catDao;
　　
　　}
　　}
　　
　　
　　那么在CatalogEJB的調用從
　　dao = CatalogDAOFactory.getDAO();
　　
　　要改為
　　dao = CatalogDAOFactory.getIntance();
　　Facade模式
　　
　　在EJB應用中，有兩個端點，這一端是用戶端，另外一端是EJB,通常在這兩個端點間會增加一層，用來松散兩個端點之間的耦合，比如在寵物店例子中,考慮到不同身份的用戶有不同的操作流程，比如顧客注冊進入后，需要瀏覽目錄，下訂單，而商店治理者進入后需要確認或者否定訂單，或者檢查庫存。這些功能需要借助session bean和Entity bean完成。
　　
　　但是假如用戶端直接和這些bean互動,會有以下問題:
　　
　　1. 用戶端必須注重和這些beans的所有有聯系或互動的事情，無法阻止用戶端可能不恰當的使用這些beans.
　　2.假如EJB的API改動，那么用戶端的一些代碼也要修改。無疑擴展性很差。
　　3.即使這些beans都在同一臺服務器上，用戶端還是用remote方式來調用它們，造成網絡無故擁擠。
　　
　　那么我們使用Facade模式來解決這個問題，Facade的定義是為子系統中的一組接口提供一個一致的界面,很顯然我們需要為這些bean提供一個統一的對外界面。如下圖：
　　設計模式在EJB中的應用(下)

　　在寵物店中，ShoppingClientFacadeLocalEJB是面對所有用戶端操作的統一界面，用戶端操作就不直接和那些EJB如CustomerEJB或ShoppingCartEJB有聯系,而是都通過ShoppingClientFacadeLocalEJB來聯系的。代碼如下：
　　
　　public class ShoppingClientFacadeLocalEJB implements SessionBean {
　　...
　　
　　//和CustomerEJB聯系
　　public CustomerLocal getCustomer() throws FinderException {
　　　　if (userId == null) {
　　　　　　...
　　　　}
　　　　try {
　　　　　　InitialContext ic = new InitialContext();
　　　　　　Object o = ic.lookup("java:comp/env/ejb/petstore/local/customer");
　　　　　　CustomerLocalHome home =(CustomerLocalHome)o;
　　　　　　customer = home.findByPrimaryKey(userId);
　　　　} catch (javax.naming.NamingException nx) {
　　　　　 ...
　　　　}
　　
　　　　return customer;
　　}
　　
　　.....
　　
　　//和ShoppingCartEJB聯系
　　public ShoppingCartLocal getShoppingCart() {
　　　　if (cart == null) {
　　　　　　try {
　　　　　　　　InitialContext ic = new InitialContext();
　　　　　　　　Object o = ic.lookup("java:comp/env/ejb/cart/Cart");
　　　　　　　　ShoppingCartLocalHome home =(ShoppingCartLocalHome)o;
　　　　　　　　cart = home.create();
　　　　　　} catch (javax.ejb.CreateException cx) {
　　　　　　　...
　　　　　　}
　　　　}
　　　　return cart;
　　}
　　
　　....
　　
　　}
　　
　　
　　Facade模式參與者：
　　
　　SessionFacade (ShoppingClientFacadeLocalEJB)
　　
　　提供一組操作流程
　　
　　將真正工作委托到EJB的bean.
　　
　　EJB的bean (CustomerEJB, ShoppingCartEJB等等)
　　
　　執行基本的商業邏輯操作
　　
　　沒有任何對SessionFacade的調用.
　　
　　這樣不但可擴展性大大增強，效率也提高了，用戶端只需要一次Remote對SessionFacade調用就可以了，而SessionFacade會自動定位到與它同一臺服務器的那些鄰居bean(CustomerEJB, ShoppingCartEJB等等),無疑減少網絡擁擠，提高了速度.
　　
　　總結
　　
　　在EJB的具體使用中，使用合適的設計模式，不但使代碼可重用性可拓展性增強，最重要的是能提高效率和速度，我們知道EJB框架由于考慮大型系統中事務安全等各方面問題，效率性能有所欠缺，那么我們在具體問題具體應用時，使用設計模式可以彌補這個問題。
　　
　　例如Proxy模式可以為我們在訪問巨大的需要花費一定時間才能展開的對象時，提供一個代理，這樣不會因為那個巨大對象而影響當前運行速度，EJB中的那些bean很顯然屬于巨大對象（因為它們有反復的數據庫操作，這些很費時間〕。
　　
　　Flyweight模式是避免大量擁有相同內容的小類的開銷(如耗費內存),使大家共享一個類(元類).當你要從EJB中獲取一系列字符串,而這些字符串中肯定有許多是重復的,那么我們可以將這些重復的字符串儲存在Flyweight池(pool)中以達到共享。

上一篇：使用設計模式改善程序結構

下一篇：設計模式的原則