|
|
系列文章導(dǎo)航：
不能不說的C#特性-迭代器(上)及一些研究過程中的副產(chǎn)品
不能不說的C#特性-迭代器(下)，yield以及流的延遲計算
走進(jìn)Linq-Linq to Objects(上)基礎(chǔ)篇
走進(jìn)Linq-Linq to Objects(下)實例篇
走進(jìn)Linq-Linq to SQL感性認(rèn)識篇
走進(jìn)Linq-Linq to SQL How do I(1)
走進(jìn)Linq-Linq to SQL How do I(2)
走進(jìn)Linq-Linq to SQL How do I(3)
走進(jìn)Linq-How do I(4)拾遺補零篇第一節(jié)
走進(jìn)Linq-Linq to SQL源代碼賞析 Table
走進(jìn)Linq-Linq to SQL源代碼賞析之Provider的初始化
走進(jìn)Linq-Linq to SQL源代碼賞析，通過Linq to SQL看Linq
話說Linq to SQL理論上應(yīng)該支持多種數(shù)據(jù)庫的，而且應(yīng)該支持多種數(shù)據(jù)庫，到最后卻落的這個局面，是為了商業(yè)考慮還是本來技術(shù)就不成熟？不得而知。不過不管怎么說Linq to SQL的體系結(jié)構(gòu)確實是支持?jǐn)U展的。
在System.Data.Linq.Mapping這個命名空間下微軟提供了一個特性：ProviderAttribute，使用強類型的DataContext或使用Xml做映射的時候，該特性可以用來指定具體的數(shù)據(jù)庫提供者。如下：
[Database(“dbo.cnblogs”)][Provider(typeof(SqlProvider))]
Public CnBlogDataContext : DataContext
{
}
系列文章導(dǎo)航：
不能不說的C#特性-迭代器(上)及一些研究過程中的副產(chǎn)品
不能不說的C#特性-迭代器(下)，yield以及流的延遲計算
走進(jìn)Linq-Linq to Objects(上)基礎(chǔ)篇
走進(jìn)Linq-Linq to Objects(下)實例篇
走進(jìn)Linq-Linq to SQL感性認(rèn)識篇
走進(jìn)Linq-Linq to SQL How do I(1)
走進(jìn)Linq-Linq to SQL How do I(2)
走進(jìn)Linq-Linq to SQL How do I(3)
走進(jìn)Linq-How do I(4)拾遺補零篇第一節(jié)
走進(jìn)Linq-Linq to SQL源代碼賞析 Table
走進(jìn)Linq-Linq to SQL源代碼賞析之Provider的初始化
走進(jìn)Linq-Linq to SQL源代碼賞析，通過Linq to SQL看Linq
關(guān)于設(shè)計模式的旁白
橋接模式
看到這里也許大家都說，哦，原來實際的事情都是這個IProvider干的啊，IProvide是個接口，下面可能有SqlProvider，OracleProvider，AccessProvider，只要提供這些Provider我們就可以無限擴(kuò)展數(shù)據(jù)庫了。是的，設(shè)計到這一步已經(jīng)可以滿足多數(shù)據(jù)庫的要求了，但是數(shù)據(jù)庫種類的多樣性只是一個方面，還有每種數(shù)據(jù)庫版本的差異呢？如果我們就使用繼承，就這樣無限的去擴(kuò)展，最后會得到一個很復(fù)雜的類層次，層次搞復(fù)雜后不僅僅難于重構(gòu)，更要的是會出現(xiàn)很多重復(fù)，靈活性也降低了。
如果光使用繼承，我們可能會得到這樣的繼承樹：
這樣的繼承層次看起來貌似很“專業(yè)”，但是靈活性實在是不敢恭維，首先，任何一個層次的小小變動在整個繼承鏈上都要改動，如果增加一種數(shù)據(jù)庫，而這種數(shù)據(jù)有會有幾種版本，各個版本之間又有些差異，那么類的數(shù)量會成倍增長。還有一個，那就是子類之間有可能造成重復(fù)，假如Sql2000Provider和Oracle9iProvider之間有重復(fù)怎么辦？C#又不支持多繼承，我們無法使用Martin Folwer的重構(gòu)方法將子類重復(fù)的部分提升到父類。那有什么好辦法呢？看看微軟的設(shè)計師是怎么干的。
不能不說的C#特性-迭代器(上)及一些研究過程中的副產(chǎn)品 不能不說的C#特性-迭代器(下)，yield以及流的延遲計算 走進(jìn)Linq-Linq to Objects(上)基礎(chǔ)篇 走進(jìn)Linq-Linq to Objects(下)實例篇 走進(jìn)Linq-Linq to SQL感性認(rèn)識篇 走進(jìn)Linq-Linq to SQL How do I(1) 走進(jìn)Linq-Linq to SQL How do I(2) 走進(jìn)Linq-Linq to SQL How do I(3) 走進(jìn)Linq-How do I(4)拾遺補零篇第一節(jié) 走進(jìn)Linq-Linq to SQL源代碼賞析 Table 走進(jìn)Linq-Linq to SQL源代碼賞析之Provider的初始化 走進(jìn)Linq-Linq to SQL源代碼賞析，通過Linq to SQL看Linq系列文章導(dǎo)航：
IProvder的初始化方法Initialize需要兩個參數(shù)，其中一個就是一個IDataService接口（注意，這里是接口，那肯定有很多實現(xiàn)，不過由于Linq to SQL就支持一種數(shù)據(jù)庫，現(xiàn)在也只有一種實現(xiàn)了，不過我們可以通過這種形式來想象和擴(kuò)展，并可以學(xué)習(xí)這種理念），這個時候我們得到的是另外一種類圖：
這里以組合的方式，組合Provider和IDataService，類的繼承層次簡明了很多，也可以很容易處理子類之間的重復(fù)了。
實際上這就是橋接模式，該模式的意圖是抽象和實現(xiàn)相分離，在這里IProvider就是抽象，而IDataService這邊就是實現(xiàn)了。通過IDataService這個接口，把SqlProvider和CommonDataService，DBProvider和DBDataService之間的依賴消除了。仔細(xì)體會一下，我們的實際項目中在哪些地方出現(xiàn)過這樣的場景？不久以前我發(fā)了一篇博客《重構(gòu)到Brdge模式》，那里描述了我實際項目中一個真實的場景。
請注意的是，實際的Linq to SQL因為只支持SQL Server，所以上面的類圖描述的關(guān)系并不存在，但是我們從代碼中完全可以想象的到即使要擴(kuò)展也是很容易的，這就是架構(gòu)的力量，即使是昨天的設(shè)計也能應(yīng)付明天的變化。
關(guān)于Provider的初始化就介紹到這里了，在文章末尾的源代碼下載里提供了IProvider類和SqlProvider類，你可以看看初始化的過程，并聯(lián)系上面的圖想想如何構(gòu)建一個可擴(kuò)展的架構(gòu)。
Linq to SQL源代碼下載，注意不是完整源代碼，不能通過編譯，我會逐漸增加源代碼
it知識庫：走進(jìn)Linq-Linq to SQL源代碼賞析之Provider的初始化，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
