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

　　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) iclookup(JNDINamesCATALOG_DAO_CLASS);
　　　　　　catDao = (CatalogDAO) ClassforName(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) iclookup(JNDINamesCATALOG_DAO_CLASS);
　　　　　　　　catDao = (CatalogDAO) ClassforName(className)newInstance();
　　　　　　} catch (NamingException ne) {
　　　　　　　　
　　
　　　　　　}
　　　　 }
　　　　return catDao;
　　
　　}
　　}
　　
　　
　　那麼在CatalogEJB的調用從
　　dao = CatalogDAOFactorygetDAO();
　　
　　要改為
　　dao = CatalogDAOFactorygetIntance();
　　Facade模式
　　
　　在EJB應用中有兩個端點這一端是用戶端另外一端是EJB通常在這兩個端點間會增加一層用來松散兩個端點之間的耦合比如在寵物店例子中考慮到不同身份的用戶有不同的操作流程比如顧客注冊進入後需要浏覽目錄下訂單而商店管理者進入後需要確認或者否定訂單或者檢查庫存這些功能需要借助Session bean和Entity bean完成
　　
　　但是如果用戶端直接和這些bean互動會有以下問題:
　　
　　 用戶端必須注意和這些beans的所有有聯系或互動的事情無法阻止用戶端可能不恰當的使用這些beans
　　如果EJB的API改動那麼用戶端的一些代碼也要修改無疑擴展性很差
　　即使這些beans都在同一台服務器上用戶端還是用remote方式來調用它們造成網絡無故擁擠
　　
　　那麼我們使用Facade模式來解決這個問題Facade的定義是為子系統中的一組接口提供一個一致的界面很顯然我們需要為這些bean提供一個統一的對外界面如下圖
　　
　　在寵物店中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 = iclookup(java:comp/env/ejb/petstore/local/customer);
　　　　　　CustomerLocalHome home =(CustomerLocalHome)o;
　　　　　　customer = homefindByPrimaryKey(userId);
　　　　} catch (javaxnamingNamingException nx) {
　　　　　
　　　　}
　　
　　　　return customer;
　　}
　　
　　
　　
　　//和ShoppingCartEJB聯系
　　public ShoppingCartLocal getShoppingCart() {
　　　　if (cart == null) {
　　　　　　try {
　　　　　　　　InitialContext ic = new InitialContext();
　　　　　　　　Object o = iclookup(java:comp/env/ejb/cart/Cart);
　　　　　　　　ShoppingCartLocalHome home =(ShoppingCartLocalHome)o;
　　　　　　　　cart = homecreate();
　　　　　　} catch (javaxejbCreateException 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)中以達到共享
　　
　　

From:http://tw.wingwit.com/Article/program/Java/gj/201311/27393.html