實戰 .Net 數據訪問層 - 11
2024-07-10 13:03:21
供稿：網友
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;
}
...
}
