實戰 .Net 數據訪問層 - 12
2024-07-10 13:03:21
供稿：網友
本文來源于網頁設計愛好者web開發社區http://www.html.org.cn收集整理，歡迎訪問。從這個dalbase很容易看出，framework level的支持主要集中
在cache management和distributed process上面，這也幾乎是所
有data access logic都不得不考慮的現實問題（可能在實際項目中，
data access logic level的distributed process需求不會很多，大部分
都在business logic中直接解決了）！
以下，就讓我們看看制造一個真正的data access logic是多么的
方便j
代碼10：打造自己的data access logic
// mydal：提供當前應用程序所需的數據訪問支持，從dalbase繼承
public class mydal : dalbase
{
public mydal() { }
}
// customerdal_adox：提供使用傳統ado.net進行數據訪問的支持，從mydal繼承
class customerdal_adox : mydal
{
public customerdal_adox() { }
protected internal mycustomer getcustomerbyid(string strid)
{...}
protected internal void updatecustomer(mycustomer cust)
{...}
...
}
// customerdal_orm：提供使用o/r mapping進行數據訪問的支持，從mydal繼承
class customerdal_orm : mydal
{
public customerdal_orm() { }
protected internal mycustomer getallcustomers()
{...}
protected internal void updatecustomers (mycustomer cust)
{...}
...
}
上面代碼中的mydal并未真正實現什么操作，純粹為了擴展而設置，用戶也可以類似daf中那樣，繞過mydal這層，直接讓
customerdal_adox或customerdal_orm從dalbase繼承，這會使
我們的系統結構顯得更加簡潔明了。
從上面的代碼中，我們很容易地發現，所有data access logic
方法全部被聲明為protected internal，why？
當然還是因為那個“可恨的”daf！接口一致性的代價就在這里
體現出來了（真可惡啊，前面說了那么多天花亂墜的原因，到了這
么后面才談daf的缺點j）！
雖然被“剝奪”了在代碼中直接點出data access logic方法的“快
感”，但如果您真的非常需要這么做（強烈不推薦j），還是有如下3
個辦法的（當然了，作者是非常不希望您就這么將daf打入冷宮，
畢竟也花了好多心血和篇幅大大的宣傳了一番啊j）：
（1） 將您的訪問代碼與data access logic編譯進一個assembly中，這樣，神奇的internal就會使您心想事成（daf、data access logic同屬data access模塊，一般打進一個assembly編譯，所以天然具有了internal魔力j）！付出的代價則是：您不得不將business logic（或其它調用模塊）與data access放在同一個layer中l，失去了一個良好設計的系統所應有的層次感和靈活性！
（2） internal是深具.net特色的3大慣用法寶之一（提醒：請勿濫用l），另一武器當然就是我們的reflection啦！
ok，也不用您自己出手，系統早已準備了helper供您享用：
public static object invokemethod(
type type, string method, object[] paramsvalue)
（3） 如果手癢或嫌系統提供的方法不好用，那就只有自己出馬了，相信，您對reflection也早已滾瓜爛熟，三下五除二就能輕松拿下了（不過，作者還是要提醒一句：千萬不要濫用！protected的設計意圖非常明確，慎之慎之l）！
說了那么多，還是一句話：快用daf吧，它（也）會讓您快樂
的j！
不過，有一個問題也需要向大家交待清楚：這里，作者為何沒有
使用factory pattern來構造不同的data access logic實現（不使用
factory的代價是需要提供到method級別的大量配置信息，確實有點
麻煩l）？
這主要基于2個考慮：
（1） data access logic不一定會遵守daf的一致性原則，data entity也不盡相同（對于遺留data access logic代碼，甚至連參數都有可能存在差異），這種情況下，定義一個generic interface有一定困難；
（2） 并不是每個data access logic都會實現daf要求的所有功能（比如：上面的代碼10中，就是通過customerdal_adox與customerdal_orm這兩個data access logic來共同構筑起面向customer進行數據訪問的全部功能。試想一下，如果采用了factory，豈不是“與我何干”的東東也要被迫全盤接受？而且，即使寫個空方法接受了，又如何實現對其它data access logic的真正調用（寫這樣的factory可真有點難度啊？
下一段：http://www.csdn.net/develop/read_article.asp?id=27555
