「ADO.NET 2.0の注目機能【SQL Server 2005との連携編】」で，私はADO.NET 2.0の新機能のうちSQL Server 2005向けのものをいくつか取り上げた。今回は，ADO.NET2.0で使われるオブジェクトを紹介しようと思う。
あなたがどのバージョンを使っていても，トップ・レベルではSystem.DataネームスペースがADO.NETを表す。このネームスペース内のクラスは，様々なデータ・アクセス・メソッドすべてにわたって適合する。例えば，DatasetクラスとDataTableクラスは，ADO.NETの様々な実装にわたって共通に使えるものだ。データを検索するために使われるデータ・ソースにかかわらず，こうしたオブジェクトの振る舞いを信頼してよい。それらが下層にあるデータ・ソースを抽象化するからだ。しかし，前バージョンのADO.NET 1.0では，この標準的な抽象化に例外があった。そういった例外の1つはSystem.Data.SQLClientネームスペース下で定義されたSQLDataReaderクラスである。この順方向のみのカーソルは，ADO.NET 1.0下にあるSQL Serverクライアントだけが使える。
ADO.NET 2.0がいくつかのアクセス・メソッド・ネームスペースの中で定義された様々なクラスをうまく抽象化するのをどう助けているかを話す前に，DataTableReaderという名前の新しいクラスを紹介しておきたい。この新しいオブジェクトは，System.Dataネームスペース内で定義されている。つまり，このことはADO.NET 2.0下でサポートされるデータベース・プロバイダのどれかで利用できるということを示している。このオブジェクトは，利用可能なクラスのリストに対する優れた追加である。しかし，この新しいオブジェクトの名前から早合点しないよう，あなたに警告しておきたい。
あなたは「DataTableオブジェクトのように，DataTableReaderオブジェクトが単一のデータ・テーブルを表すのだ」と，間違って理解するかもしれない。そうではない。DataTableReaderは，実際には1つまたは複数のテーブル上で，リード・オンリーかつフォワード・オンリーの操作をするために使われるのだ。だから，もし全データ・セットを巡回したいのなら，DataTableReaderを使いそのデータ・セット内の全テーブルを巡回できる。
データ・テーブルを巡回して行を取り出すのにサーバー・サイド・カーソルを使うSqlDataReaderとは違い，DataTableReaderは横断する対象のデータ・テーブルのキャッシュ・コピーを利用する。だから，通常使われるリーダーとSQLDataReaderにはいくつかの違いがある。一番大きな違いは，DataTableReaderのコンストラクタはパラメータとしてDataTableかDataSetオブジェクトを必要とすることだ。多くの解釈の中で，DataTableReaderを理解する最良の解釈は，DataTableオブジェクトの拡張と見ることだ。このオブジェクトのリーダー版は，リーダーに期待するのと同じフォワード・オンリーの振る舞いを効果的にエミュレートする手段を単純に提供している。
DataTableReader以上の大きな変更が，ADO.NET 2.0のクラスの階層に起きている。ADO.NET 1.0では，System.Data.CommonネームスペースにDataAdapterオブジェクトの一般的なバージョンが付いてくる。このオブジェクトは，DataTableとDataReaderオブジェクトの作成に使えるものだ。あなたは自分のアプリケーションからデータ・ソースを抽象化するために，これら3つのオブジェクトを使用できる。しかし，ADO.NET 1.0ではCommandやConnectionと同じような他のデータベース・クラスをサポートしない。だから，あなたのアプリケーションは，結果的に特定のデータ・ソースに対してだけ使えるように，制限されてしまうことがある。例えば，OracleからSQL Server 2005への移行が必要になった場合，あなたは新しいデータ・プロバイダに合わせてコードを書き換えなくてはならない。特定のタイプのコネクションを参照するビジネス・ロジックのコードを書かなければいけないことは，そのアプリケーションが異なる種類のデータベースで動作するのを制限する。
ADO.NET 2.0は，この点が改善されていする。ADO.NET 2.0内では，System.Data.Commonネームスペースが，一般的に使うConnectionやCommandや関連するオブジェクトを含むように，拡張されている。新しいベース・クラスを使うと，自分のビジネス・ロジック内で一般的なCommandオブジェクトが使える。どのデータ・アクセス・プロバイダが使われているかを意識する必要があるコードは，コマンドやコネクションを生成するための設定を読むコードだけだ。この新しいベース・オブジェクトは様々なデータ・ソースから抽象化したレイヤーを提供する。だから，あなたは自分のアプリケーションのコードに大きな影響を与えず，下層にあるデータ・ソースを変更できる。
ADO.NET 2.0に新しいベース・クラスを実装するため，Microsoftはデータ・プロバイダ・クラスによって使われる継承モデルを完全に変更した。データ・プロバイダ・クラスの大半にSystem.Componentsを継承させるのではなく，System.Data.Commonネームスペース内のクラスのセットから継承させるようにしたのだ。
だから，SqlConnectionオブジェクトのインスタンスを参照するADO.NETコードを書く代わりに，あなたはSqlConnectionオブジェクトを生成し，次にそのオブジェクトをあなたのビジネス・ロジックにDbConnectionオブジェクトとして渡せばよい。そうすることで，アプリケーション側だけに関係するコードは，それが使っているデータ・コネクションのタイプを意識しなくなる。あなたはSQL Server用のプロバイダーを使うことであらゆるメリットが得られるが，データ・ソース独特の処理は内部で行われる。
System.Data.Commonクラスに関する詳細な情報を入手するには，Microsoft Developer Network（MSDN）にある「Visual Studio 2005 Library」のチェックをお勧めする。ほかの情報源としては，やはりMSDNの記事（「ADO.NET 2.0 基本クラスおよびファクトリによる汎用的なコーディング」）がある。
