<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
4. Data Access Logic
討論Data Access Logic（爲了不和Data Access Layer混淆，文中
所有涉及Data Access Logic的部分將全部使用全稱描述，DAL僅指Data Access Layer）前，讓我們先看一看它的結構示意圖：
<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />
咦！怎麼回事？看上去長得與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; } ... } |
下一段：http://www.csdn.net/develop/Read_Article.asp?id=27554