實戰 .Net 資料訪問層 - 11

訪問|資料 4. Data Access Logic

討論Data Access Logic（為了不和Data Access Layer混淆，文中

所有涉及Data Access Logic的部分將全部使用全稱描述，DAL僅指Data Access Layer）前，讓我們先看一看它的結構示意圖：






咦！怎麼回事？看上去長得與DAF非常相似嘛！難道這就是作

者“不辭辛勞”單獨開闢一個小節來進行“大肆宣傳”的Data Access

Logic嗎？

沒錯！這就是Data Access Logic！它是和DAF長得有點像，但

絕對不是孿生兄弟，它所起的作用也和DAF完全不同！



首先需要聲明的是，Data Access Logic與DAF間的相似性確實

存在，但也就體現在如下兩個方面（作者認為這並不是其主要特性）：

（1） 它們都採用了2次繼承模式；

（2） Data Access Logic的前兩層（DalBase / MyDal）作用大致相當於DAF中的前兩層作用，分別在Framework Level和Application Level提供一些基礎服務。



但是，除此之外，作者需要特彆強調的是，Data Access Logic的

關鍵特性並不在這前兩層（DAF則有點不同，它的前兩層非常重要），

而是在真正實現了具體Data Access Logic的第3層中！

打個簡單比方：DAF有點像.NET中的Interface，而Data Access Logic則更像ImplementationJ。

那麼，作者為何不直接將DAF聲明為Interface而令Data Access Logic直接繼承之呢？到底是什麼原因令我們必須將它們嚴格分開，並在不同的Layer中進行處理呢？



其實，原因在上面已經分析了一部分（DAF需要確保介面聲明一致，資料實體一致，而Data Access Logic則無此限制），另一部分原因則在於，DAF對外需要統一公布所有介面，而Data Access Logic則可以相對靈活地進行不同處理。例如：可以將ADO.NET相關的資料訪問操作集中在一個地方，而XML相關的處理放置則可以在另一個地方進行實現（是不是更有利於細化分工J）！



還有兩種情況可能也需要支援這種變化：

（1） 目前的版本中，我們使用了某種方法實現Data Access Logic，例如：O/R Mapping，可是在後續版本中，由於某些原因（效能/複雜度），我們需要改用DataSet方式進行互動，這時候，我們為DataSet撰寫的新方法就可以非常方便的替換現有的O/R Mapping方法（只要修改一下配置資訊），而對外介面（DAF）則根本不必修改（當然了，原來針對O/R Mapping返回資料進行處理的那些代碼是必須要修改的，但這並不會破壞Cross Layer間的介面一致性）！

（2） 系統中可能會存在一些遺留Data Access Logic代碼，這部分東東棄之可惜，食之則餘香依舊，怎麼辦呢？很簡單，交給DAF處理吧！我們可以單獨建立一個Data Access Logic模組（例如：CustomerDal_LEGACY）專門包含這部分代碼，然後，在DAF中使用Adapter Pattern將其統統歸入門下（當然了，也可以在這個專用Data Access Logic模組中直接封裝，但作者更喜歡使用DAF幹這樣的雜事J）！



Ok，文字看累了，來段代碼瞅瞅：



代碼9：掀起Data Access Logic的蓋頭來！

// DalBase：提供大部分應用程式所需的基本資料訪問支援，

// 包括分散式處理，資料緩衝支援等

public class DalBase

{

public DalBase() { }



protected string GetDistributionType()

{

string strType = null;

... // 根據當前調用上下文和設定檔得到所需資料

return strType;

}

protected CacheParam GetCacheParam()

{

CacheParam param = null;

... // 根據當前調用上下文和設定檔得到所需資料

return param;

}

...

}