實戰 .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


相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。