實戰 .Net 資料訪問層 - 12
來源：互聯網
上載者：User
訪問|資料 從這個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
