學(xué)習(xí)筆記之ORM設(shè)計(jì)中用到的模式
by Naven at 2005-09-19
DAO 模式
DAO 模式即 Data Access Object 模式，實(shí)際是兩個(gè)模式的組合，即 Data Accessor 模式和 Active Domain Object 模式，其中 Data Accessor 模式實(shí)現(xiàn)了數(shù)據(jù)訪問和業(yè)務(wù)邏輯的分離，而 Active Domain Object 模式實(shí)現(xiàn)了業(yè)務(wù)數(shù)據(jù)的對(duì)象化封裝，一般都是將這兩個(gè)模式組合使用。
DAO 模式通過對(duì)業(yè)務(wù)層提供數(shù)據(jù)抽象層接口，實(shí)現(xiàn)了以下目標(biāo)：
1、數(shù)據(jù)存儲(chǔ)邏輯的分離：通過對(duì)數(shù)據(jù)訪問邏輯進(jìn)行抽象，為上層結(jié)構(gòu)提供抽象化的數(shù)據(jù)訪問接口。
2、數(shù)據(jù)訪問底層實(shí)現(xiàn)的分離：通過將數(shù)據(jù)訪問劃分為抽象層和實(shí)現(xiàn)層，從而分離了數(shù)據(jù)使用和數(shù)據(jù)訪問的底層實(shí)現(xiàn)細(xì)節(jié)。
3、資源和調(diào)度的分離：將數(shù)據(jù)訪問邏輯從業(yè)務(wù)邏輯中脫離開來，使得在數(shù)據(jù)訪問層實(shí)現(xiàn)統(tǒng)一的資源調(diào)度，通過數(shù)據(jù)庫連接池以及各種緩存機(jī)制（Statement Cache，Data Cache等）的配合使用，大幅度提升系統(tǒng)性能。
4、數(shù)據(jù)抽象：通過對(duì)底層數(shù)據(jù)的封裝，為業(yè)務(wù)層提供一個(gè)面向?qū)ο蟮慕涌冢沟脴I(yè)務(wù)邏輯開發(fā)人員可以面向業(yè)務(wù)中的實(shí)體進(jìn)行編碼。即對(duì)業(yè)務(wù)層屏蔽了數(shù)據(jù)庫訪問的底層實(shí)現(xiàn)，業(yè)務(wù)層僅包含于本領(lǐng)域相關(guān)的邏輯對(duì)象和算法。
總結(jié)來說，DAO 模式可以這么理解：
Data Accessor Object （DAO）= Data + Accessor + Domain Object
舉例來說，如下（引自《深入淺出Hibernate》）：
public Double calcAmount(String customerid, double amount)
{
// 根據(jù)客戶ID獲得客戶記錄
Customer customer = CustomerDAO.getCustomer(custmerid);
// 根據(jù)客戶等級(jí)獲得打折規(guī)則
Promotion promotion = PromotionDAO.getPromotion(customer.getLevel());
// 累積客戶總消費(fèi)額，并保存累計(jì)結(jié)果
customer.setSumAmount(customer.getSumAmount().add(amount);
CustomerManager.save(customer);
// 返回打折后的金額
return amount.multiply(protomtion.getRatio());
}
從這段代碼看出，通過 DAO 模式對(duì)各個(gè)數(shù)據(jù)對(duì)象進(jìn)行封裝，對(duì)業(yè)務(wù)層屏蔽了數(shù)據(jù)庫訪問的底層實(shí)現(xiàn)，業(yè)務(wù)層僅包含于本領(lǐng)域相關(guān)的邏輯對(duì)象和算法。
Abstract Factory 模式
Abstract Factory 模式即 抽象工廠創(chuàng)建型模式，它提供一個(gè)創(chuàng)建一系列相關(guān)或相互依賴對(duì)象的接口，而無需制定它們具體的類。換句話說，就是向調(diào)用者提供一個(gè)接口，使得在不必指定產(chǎn)品的具體類型情況下，創(chuàng)建多個(gè)產(chǎn)品族中的產(chǎn)品對(duì)象，這就是抽象工廠模式的用意。
作為最常用的創(chuàng)建模式，抽象工廠模式在這里起到連接接口和實(shí)現(xiàn)的橋梁作用。通過該模式，可以根據(jù)具體需要加載相應(yīng)的實(shí)現(xiàn)，并將此實(shí)現(xiàn)作為所對(duì)應(yīng)接口的一個(gè)實(shí)例提供給業(yè)務(wù)層使用。
如抽象如下接口（引自《深入淺出Hibernate》）：
public interface CustomerDAO {
public Customer getCustomer(String custid);
public void save(Customer customer);
}
業(yè)務(wù)層這樣使用：
CustomerDAO custDAO = (CustomerDAO) DAOFactory.getDAO(CustomerDAO.class);
Customer customer = custDAO.getCustomer(customerID);
也就是說，業(yè)務(wù)層通過接口調(diào)用底層實(shí)現(xiàn)，具體的DAO實(shí)現(xiàn)類不會(huì)出現(xiàn)在業(yè)務(wù)代碼中。
不過卻帶來了另一個(gè)缺憾，即混雜了一些數(shù)據(jù)訪問層的內(nèi)容，如 DAOFactory.getDAO() 方法的調(diào)用，所以還需引入 Proxy 模式加以改良。
Proxy 模式
Proxy 模式即 代理結(jié)構(gòu)型模式，它為其他對(duì)象提供一種代理以控制對(duì)這個(gè)對(duì)象的訪問。比如說 Windows 的快捷方式和 Unix 的文件/目錄的Link文件就是一種代理的例子。
引入 Proxy 模式的作用是通過提供一個(gè)中間層（Proxy），將上層調(diào)用接口與下層的實(shí)現(xiàn)相銜接，以做到保持業(yè)務(wù)代碼的簡(jiǎn)潔，消除 Factory 模式帶來的缺憾。
改進(jìn)后的業(yè)務(wù)代碼如下（引自《深入淺出Hibernate》）：
public Double calcAmount(String customerid, double amount)
{
// 根據(jù)客戶ID獲得客戶記錄
Customer customer = CustomerProxy.getCustomer(custmerid);
// 根據(jù)客戶等級(jí)獲得打折規(guī)則
Promotion promotion = PromotionProxy.getPromotion(customer.getLevel());
// 累積客戶總消費(fèi)額，并保存累計(jì)結(jié)果
customer.setSumAmount(customer.getSumAmount().add(amount);
CustomerManager.save(customer);
// 返回打折后的金額
return amount.multiply(protomtion.getRatio());
}
而在 CustomerProxy類和 PromotionProxy類中實(shí)現(xiàn)調(diào)用 CustomerDAO類和 PromotionDAO類的方法。
Decorator 模式
Decorator 模式即 裝飾結(jié)構(gòu)型模式，又名包裝（Wrapper）模式。目的是利用一個(gè)對(duì)象，透明地為另一個(gè)對(duì)象添加新的功能，是繼承關(guān)系的一個(gè)替代方案。就增加功能來說，Decorator 模式相比生成子類更為靈活。簡(jiǎn)單來說，就是通過一個(gè) Decorator 對(duì)原有對(duì)象進(jìn)行封裝，同時(shí)實(shí)現(xiàn)與原有對(duì)象相同的接口，從而得到一個(gè)基于原有對(duì)象的，對(duì)即有接口的增強(qiáng)性的實(shí)現(xiàn)。
在以下情況下應(yīng)當(dāng)使用 Decorator 模式：
1、需要擴(kuò)展一個(gè)類的功能，或給一個(gè)類增加附加責(zé)任。
2、需要?jiǎng)討B(tài)地給一個(gè)對(duì)象增加功能，這些功能可以再動(dòng)態(tài)地撤銷。
3、需要增加由一些基本功能的排列組合而產(chǎn)生的非常大量的功能，從而使繼承關(guān)系變得不現(xiàn)實(shí)。
Decorator 模式有如下缺點(diǎn)：
使用裝飾模式會(huì)產(chǎn)生比使用繼承關(guān)系更多的對(duì)象，更多的對(duì)象會(huì)使得查錯(cuò)變得困難，特別是這些對(duì)象看上去都很相像。
舉例來說（引自《深入淺出Hibernate》）：
如果要實(shí)現(xiàn)連接池，并且在 Connection 對(duì)象使用后調(diào)用 close() 時(shí)不關(guān)閉連接，而是釋放到連接池中，則可以考慮實(shí)現(xiàn)一個(gè) ConnectionDecorator 類來做，它實(shí)現(xiàn) Connection 類所有方法，并且所有方法都轉(zhuǎn)調(diào) Connection 類的相同方法。
public class ConnectionDecorator
implements Connection {
private Connection dbconn;
public ConnectionDecorator(Connection conn) {
this.dbconn = conn; // 實(shí)際從數(shù)據(jù)庫獲得的 Connection 引用
}
/**
* 次方法將被子類覆蓋，以實(shí)現(xiàn)數(shù)據(jù)庫連接池的連接返回操作
*/
public void close() throws SQLException {
this.dbconn.close();
}
// 其他方法類似，均調(diào)用 dbconn.xxx方法
}
然后就可以實(shí)現(xiàn)一個(gè)類繼承 ConnectionDecorator，而覆蓋其 close() 方法即可，如下：
public class PooledConnection
extends ConnectionDecorator
implements Connection {
private ConnectionPool connPool;
public PooledConnection(ConnectionPool pool, Connection conn) {
super(conn);
connPool = pool;
}
/**
* 覆蓋close方法，將數(shù)據(jù)庫連接返回連接池，而不是直接關(guān)閉連接
*/
public void close() throws SQLException {
connPool.releaseConnection(this.dbconn);
}
}
同樣的道理，還可以利用 Decorator 模式對(duì) DriverManager類進(jìn)行同樣的改造，從而最小化數(shù)據(jù)庫連接池對(duì)傳統(tǒng) JDBC 編碼方式的影響.
但是由于 Decorator 模式的缺點(diǎn),會(huì)導(dǎo)致大量類似的小類，并且由于此模式要求實(shí)現(xiàn)與目標(biāo)對(duì)象一致的接口，Connection 接口中定義的方法眾多，也必須在 ConnectionDecorator 類中逐一實(shí)現(xiàn)，雖然只是簡(jiǎn)單的委托實(shí)現(xiàn)。隨意接下來引入 Dynamic Proxy 模式很好地解決了這一問題。
Dynamic Proxy 模式
Dynamic Proxy 模式是 JDK1.3 版本中引入的一種新的動(dòng)態(tài)代理機(jī)制（Dynamic Proxy），它為 Java 帶來了極佳的運(yùn)行期擴(kuò)展能力。嚴(yán)格來說，Dynamic Proxy 本身并非一種模式，只能算是 Proxy 模式的一種動(dòng)態(tài)實(shí)現(xiàn)方式。感覺有點(diǎn)像 Win32 里 hook 機(jī)制。
下面通過上面連接池的例子來解釋 Dynamic Proxy 機(jī)制（引自《深入淺出Hibernate》）：
Dynamic Proxy 模式可以解決 Decorator 模式帶來的弊端。通過實(shí)現(xiàn)一個(gè)綁定到 Connection 對(duì)象的 InvocationHandler 接口來實(shí)現(xiàn)，使得可以在 Connection.close() 方法被調(diào)用時(shí)將其截獲，并以新的 close() 方法替代，實(shí)現(xiàn)連接調(diào)用關(guān)閉方法時(shí)返回到數(shù)據(jù)庫連接池中的目的。
下面是 ConnectionHandler 類，它實(shí)現(xiàn)了 InvocationHandler 接口，按照 Dynamic Proxy 機(jī)制的定義，invoke() 方法將截獲所有代理對(duì)象的方法調(diào)用操作，這里通過 invoke() 方法截獲 close() 方法來處理。
public class ConnectionHandler
implements Invocationhandler {
Connection dbconn;
ConnectionPool pool;
public ConnectionHandler(ConnectionPool connPool) {
this.pool = connPool;
}
/**
* 將動(dòng)態(tài)代理綁定到指定 Connection 對(duì)象
*/
public Connection bind(Connection conn) {
this.dbconn = conn;
Connection proxyConn =
(Connection) Proxy.newProxyInstance(
conn.getClass().getClassLoader(),
conn.getClass().getInterfaces(),
this);
return proxyConn;
}
/**
* 方法調(diào)用攔截器
* 判斷當(dāng)前調(diào)用的方法是否 "close" 方法
* 如是，調(diào)用 pool.releaseConnection() 方法替代
*/
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
Object obj = null;
// 如果調(diào)用的方法是 "close" 方法
if( "close".equals(method.getName()) ) {
pool.releaseConnection(dbconn);
}else {
obj = method.invoke(dbconn, args);
}
return obj;
}
}
另外 DbConnectionPool.getConnection() 方法也需要做修改以使用 ConnectionHandler 類：
pubic synchronised Connection getConnection()
throws DBException {
Connection conn;
// 這里代碼從連接池中獲取一個(gè)空閑的連接，如無空閑連接，則創(chuàng)建一個(gè)新的連接
...
// 這里調(diào)用 ConnectionHandler 類來綁定獲得的連接，使之變?yōu)橐粋€(gè)連接代理返回給用戶
ConnectionHanler connHanler = new ConnectionHanler(this);
return connHanler.bind(conn);
}
到這里可以看到，基于 Dynamic Proxy 模式的實(shí)現(xiàn)相對(duì) Decorator 更加簡(jiǎn)潔明了。
參考文獻(xiàn)：1、《深入淺出Hibernate》