あまり注目されていないが、System.Dataは.NETのリレーショナルデータベースアクセスに極めて重要である。System.Dataは前進のActiveX Data Objectsに敬意を表してADO.NETとも呼ばれ、.NETデータベースドライバを構築できる汎用フレームワークを提供する。このフレームワークはデータベースドライバが従うべき規約を提供している。
接続(Connections)、コマンド(commands)、データリーダ(data readers)は全て二重継承スキームに基づいている。それぞれDbConnection, DbCommand, DbDataReaderからいくつかの基本機能を継承する。これらはまたモックのシナリオや、従来とは異なるデータソースを使用できるIDbConnection, IDbCommand, IDbDataReaderという抽象インターフェイスを実装する。この二重継承は以下のベースクラスでも使用される。
接続文字列は通常、文字列とみなされるが、DbConnectionStringBuilderを継承したオブジェクトとしてそれを表す機能がある。これは接続文字列のデータベース固有の解析が処理され、開発者は特定のデータベースに対してどの設定が利用可能かをより正確に把握できる。
System.Dataは.NETのORMよりも前だが、DbDataAdapterとDbCommandBuilder鵜kラスの実装を通じてSQLを生成する一般的な方法を提供する。通常のDataSetと型付DataSetと共に、直接と接続される。
抽象的なファクトリーパターンの実例を探しているのであれば、DbProviderFactoryを参照して欲しい。このサブクラスは、接続、コマンド、コマンドパラメータ、コマンドビルダー、データアダプターを提供する。データベース固有のロジックを書くことなく、データアクセスに必要なすべてを手にできる。
インターフェイスに関する問題
上記のようにSystem.Dataは二重継承に依存している。これは新しいメソッドを追加するときに問題になる可能性がある。例えば、.NET 4.5のDbCommandに非同期操作が追加された。しかしそれが破壊的変更になるため、IDbCommandインターフェイスには追加できなかった。つまり非同期操作と簡単にモックされた抽象インターフェイスを同時に使用することができない。
Microsoftは.NET Core 1.0の抽象インターフェイスを一度リセットできたため、(JavaがJDBCインターフェイスで実現した)抽象クラスと一致させることができた。しかし、.NET Frameworkに共有するのは困難であった。
もしC# 8にデフォルトインターフェイスメソッドが来る場合、それらを後方互換がある状態で再調整に使用できる。ただしデフォルトインターフェイスメソッドは.NET Coreのみの機能のため、.NET Frameworkとは互換性がない。古いコンパイラと他の.NET言語でも動作しない。
DbDataReader.Get*()のStringオーバーロード #31595
私たちの最初の.NET Core 3.0機能は、DbDataReader.GetXXXメソッドにカラム名を渡す機能だ。このインターフェイスに対する長い間の不満は名前でカラムを変更できないことだ。代わりにこのパターンを使用する必要がある。:
reader.GetInt32(reader.GetOrdinal("columnName"))
明確な(そしていくらか期限が過ぎた)単純化は文字列のオーバーロードを提供することだ。
reader.GetInt32("columnName")
これはすでにOracleのConnector/NETとMySqlConnectorでは完了している。
パフォーマンス上の理由から新しいメソッドはvirtualにマークされていないため、JITコンパイラが簡単にインライン化できる。また上記の理由から新しいメソッドのセットはIDbDataReaderに追加されない。
XmlDataDocument #33442
XmlDataDocumentの歴史を知っていれば、これは奇妙な選択に見えるかもしれない。XmlDataDocumentクラスは、2010年にリリースされた.NET 4.0から、将来のリリースで削除される予定であると計画が表示され、obsoleteとしてマークされていた。
これが今、取り上げられている理由はWinFormsとWPFアプリケーションがこれを使用しているからである。バグ報告では、「これはApiportから様々なカテゴリで1-7%使用されている」と述べている。
DatasetExtensions
.NET Core 3で利用できなくなる機能のひとつがDataTableExtensionsクラスである。これは6つの拡張メソッドだけでかなり簡単に見えるが、AsDataViewはSystem.Data自身を書き換えることなく構築することができない。その論理は非常に複雑で、内部メソッド、型フォワーディング、そして.NET Standardによって課題に関連している。
もし興味があるなら、DatasetExtensionsの.NET Coreへの移植 #19771、DataTable.AsDataView拡張メソッドの移植 #27610、DataViewでのキー検索を含む内部仮想メソッドの公開 #31764の会話が関連する。