System.Data雖然不引人關註,但在.NET中,System.Data對於各種關係資料庫的連線是非常重要的。System.Data也被稱為ADO.NET,其前身是ActiveX Data Objects。System.Data提供了透過的框架,在她的基礎上.NET資料驅動應用可以被構建。這個框架還提供了資料驅動程式應遵守的一些約定。
Connections,commands,data readers都是雙繼承。每個分別實現了來自於DbConnection, DbCommand,DbDataReader的基礎功能。他們也實現了抽象介面IDbConnection, IDbCommand, 和IDbDataReader,這使得它們能夠支援模擬場景和非傳統資料源。在下文描述的基礎類中都基於雙繼承方案。
雖然,connection strings一般被認為是字串,但有些工具卻認為它是繼承自DbConnectionStringBuilder的物件。它能夠處理資料庫連線字串的特定解析並幫助開發人員更好的理解特定資料庫的可用設定。
在.NET中System.Data早於ORM框架出現,但是透過實現DbDataAdapter和DbCommandBuilder,它提供了生成sql的通用方法。它可以被直接使用,也能和普通資料集及型別化資料集組合使用。
如果你想找到一個抽象工廠樣式的例子,你可以看下DbProviderFactory。它的自雷提供了connections, commands, command parameters, command builders, data adapters。其中包含了你需要的全部關於資料訪問的需求,而不僅僅是資料庫的邏輯。
介面的問題
在上文中已經提到,System.Data依賴於雙繼承。當我們想新增新的方法時,這將帶來問題。例如,非同步操作被加入到在.NET 4.5的DbCommand之中。但是卻無法將他們新增到匹配的IDbCommand介面之中,因為這將是一個破壞性的改變。這意味著您不能同時使用非同步操作和容易模擬的抽象介面。
微軟本可以在.NET Core 1.0中重新設計抽象介面,以使得其能夠與抽象類相匹配(Java透過JDBC的介面已經實現了)。然而,這卻會使得.NET Framework共用原始碼變得困難。
如果預設介面方法能夠出現在C#8.0中,在理論上,這一特徵可以用來以向後相容的方式調整介面。但是在.NET Framework中並不相容,因為預設介面方法只是.NET Core的特徵。它也不能使用較老的編譯器和其他.NET語言。
DbDataReader.Get()中的字串多載
我們對於System.Data在.NET Core 3.0之中的第一個特徵是DbDataReader的Get()方法之中能夠傳遞列名。長期以來,人們一直抱怨這個介面不能按名稱取用列。這意味著你需要使用這個樣式 。
1
|
reader.GetInt32(reader.GetOrdinal( "columnName" )) |
一個明顯的(對某些人來說,也是早就應該有的)簡化方法是提供字串多載。
1
|
reader.GetInt32( "columnName" ) |
這已經在Oracle’s Connector/NET和MySqlConnector中實現。
處於效能考慮,該方法不會被標記為虛方法,從而允許JIT編譯器輕鬆地行內它。也是由於上述原因,新的方法集不會新增到IDbDataReader中。
XmlDataDocument
如果你瞭解XmlDataDocument的歷史,這似乎是一個奇怪的選擇。在2010年釋出的.NET 4.0之中,其已經被標記為過時的,並提出了XmlDataDocument在未來的版本中將會被刪除的警告。現在使用它的原因是一些WinForms和WPF應用程式使用它,在bug報告中稱,其在Apiport的各種類別中有1-7%的使用率。
DatasetExtensions
DataTableExtensions在.NET Core 3之中將不再支援。雖然它看起來只是有6個擴充套件方法的類,但是在不修改System.Data的情況下,我們無法構建AsDataView方法。原因相當的複雜,涉及內部方法、型別轉發和.NET Standard帶來的挑戰。
原文地址:https://www.cnblogs.com/SuperChan/p/10286544.html