什么是設計模式
設計模式是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。
毫無疑問，設計模式于己于他人于系統都是多贏的，設計模式使代碼編制真正工程化，設計模式是軟件工程的基石，如同大廈的一塊塊磚石一樣。
GoF的“設計模式”是第一次將設計模式提升到理論高度，并將之規范化，本書提出了23種基本設計模式，自此，在可復用面向對象軟件的發展過程中，新的大量的設計模式不斷出現。
設計模式和框架
現在，可復用面向對象軟件系統現在一般劃分為三大類：應用程序 工具箱和框架(Framework),我們平時開發的具體軟件都是應用程序；Java的API屬于工具箱;而框架是構成一類特定軟件可復用設計的一組相互協作的類。EJB（Enterprise JavaBeans）是Java應用于企業計算的框架.
框架通常定義了應用體系的整體結構 類和對象的關系等等設計參數，以便于具體應用實現者能集中精力于應用本身的特定細節。框架主要記錄軟件應用中共同的設計決策，框架強調設計復用，因此框架設計中必然要使用設計模式.
另外，設計模式有助于對框架結構的理解，成熟的框架通常使用了多種設計模式,如果你熟悉這些設計模式，毫無疑問，你將迅速掌握框架的結構，我們一般開發者如果突然接觸EJB J2EE等框架，會覺得特別難學，難掌握，那么轉而先掌握設計模式，無疑是給了你剖析EJB或J2EE系統的一把利器。
EJB中的設計模式
下面我們從設計模式的角度看看EJB的框架是怎樣的？在這之前假設你已經大概了解了設計模式。專門的設計模式闡述請見我的設計模式之系列.
EJB是采取多層結構，原先我們數據庫開發基本是應用程序(商業邏輯運算)直接調用數據庫驅動，在EJB中，為將商業邏輯計算和數據庫截然分開，使用多個結構式模式:Adapter模式和Bridge模式等.這樣做的好處顯然有三個：
1.分離了商業邏輯層和數據訪問層;
2.能同時支持多個數據庫；
3.但數據庫類型更換時，不會設計到商業邏輯代碼的大量修改.
EJB中將對數據庫進行調用(如發出select等語句)稱為會話bean(Sessionbean),而將對應數據庫一個個記錄的bean稱為實體bean(Entity bean);由這兩種類型的bean完成對數據庫的訪問.
會話bean一般和客戶端應用是一一對應，而和數據庫端聯系緊密的是實體bean,EJB在實體bean(或直接在會話bean)和數據庫之間使用了Adapter模式和Bridge模式，無意在實體bean和數據庫之間又多了一層，稱之為DAO(Data Access Object )，DAO實際就是設計模式的混合體.
我們以Java的寵物店中的Catalog為例,這是專門處理寵物店中的寵物類別,在對數據庫訪問中，有兩個主要程序：CatalogEJB和CatalogDAO,我們從具體代碼中看看設計模式是怎么應用的.
Bridge模式和Adapter模式
我們首先看看CatalogEJB代碼：
public class CatalogEJB implements SessionBean {
protected CatalogDAO dao;
//從DAO工廠中獲取一個DAO 這是調用工廠(factory)模式的一個實例
public void ejbCreate() {
try {
dao = CatalogDAOFactory.getDAO();
}
catch (CatalogDAOSysException se) {
Debug.println("Exception getting dao " + se);
throw new EJBException(se.getMessage());
}
}
....
}
我們發現在CatalogEJB中并沒有通常的會話bean那樣有對數據庫操作的"select .. from ."等之類SQL操作語句，這些都被封裝到DAO的具體實現中(Concrete class).
在Catalog這個示例中使用了設計模式的Bridge模式,判斷是否是某種模式，主要依據其參與者的種類和相互關系，我們先看看Bridge模式的定義和參與者：
Bridge模式是將抽象和行為劃分開來,各自獨立,但能動態的結合起來（好象搭建了一座橋）。在本例中，是將商業邏輯和數據庫訪問這樣的行為劃分開來，數據庫訪問專門放置在DAO中了。
Bridge模式需要兩個接口(抽象類和接口通稱為接口)，一個用來封裝抽象部分，本例中是封裝商業邏輯，是CatalogEJB;還有一個是封裝行為(Implementor)，本例中是CatalogDAO,看看CatalogDAO代碼：
public interface CatalogDAO {
public Category getCategory(String categoryID, Locale l)
throws CatalogDAOSysException;
public Page getCategories(int start, int count, Locale l)
throws CatalogDAOSysException;
public Product getProduct(String productID, Locale l)
throws CatalogDAOSysException;
public Page getProducts(String categoryID, int start, int count, Locale l)
throws CatalogDAOSysException;
public Item getItem(String itemID, Locale l)
throws CatalogDAOSysException;
public Page getItems(String productID, int start, int size, Locale l)
throws CatalogDAOSysException;
public Page searchItems(String query, int start, int size, Locale l)
throws CatalogDAOSysException;
}
Bridge模式中參與者還需要有行為接口的具體實現(ConcreteImplementor),在本例中是CatalogDAOImpl,雖然在目前寵物店中只有一個ConcreteImplementor,但是可擴展為到Mysql XML等數據源訪問,比如你可以自己新增一個叫CatalogDAOImplMysql，也是作為CatalogDAO的子類。
看看CatalogDAO的一個子類CatalogDAOImpl的代碼：
public class CatalogDAOImpl implements CatalogDAO {
protected static DataSource getDataSource()
throws CatalogDAOSysException {
try {
InitialContext ic = new InitialContext();
return (DataSource) ic.lookup(JNDINames.CATALOG_DATASOURCE);
}
catch (NamingException ne) {
throw new CatalogDAOSysException("NamingException while looking "
+ "up DB context : "
+ ne.getMessage());
}
}
//具體Select語句在這里出現，這里主要是Oracle 數據庫的訪問語句
public Category getCategory(String categoryID, Locale l)
throws CatalogDAOSysException {
Connection c = null;
PreparedStatement ps = null;
ResultSet rs = null;
Category ret = null;
try {
c = getDataSource().getConnection();
ps = c.prepareStatement("select a.catid, name, descn "
+ "from (category a join "
+ "category_details b on "
+ "a.catid=b.catid) "
+ "where locale = ? "
+ "and a.catid = ?",
ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY);
ps.setString(1, l.toString());
ps.setString(2, categoryID);
rs = ps.executeQuery();
if (rs.first()) {
ret = new Category(rs.getString(1).trim(),
rs.getString(2),
rs.getString(3));
}
rs.close();
ps.close();
c.close();
return ret;
}
catch (SQLException se) {
throw new CatalogDAOSysException("SQLException: "
+ se.getMessage());
}
....
}
Bridge模式參與者總結如下：
商業邏輯抽象類 (CatalogEJB)
抽象的商業邏輯操作.
對DAOImplementor調用.
不關心是具體什么數據源被使用(無論是Oracle還是JDBC還是XML).
DAO(Data Access Object) (CatalogDAO)
對數據源的抽象操作行為.
提供了非常方便訪問和維護管理數據的API結構.
DAOImplementor (CatalogDAOImpl 有可能有CatalogDAOImplSybase CatalogDAOImplMysql 等)
實現具體的DAO接口內容.
使用Adapter模式，將特定的數據源驅動接口適配到DAO接口中去
數據源 ( Oracle, or Sybase database via JDBC API)
提供訪問具體數據庫的驅動接口，如包括連接池等.
在使用數據源驅動接口時，需要使用Adapter模式，Adapter模式將兩個不相關的類糾合在一起使用，Adapter模式實際是使用組合(composition)和繼承(inheritance)兩種方式再生類，在著名的"think in Java"的"類再生"專門提到這兩個方式.
很顯然，如果你對Bridge模式和Adapter模式熟悉，那么對寵物店中的Catalog理解就會非常快，同樣，在寵物店其他部分如訂單 用戶注冊 等都能迅速理解。
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提供一個統一的對外界面。如下圖：
在寵物店中，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)中以達到共享。
|
|