ASP.NET（の中の主にVB.NET）に関する覚え書き第2弾。DBアクセス周りについて。

従来のASP（Active Server Pagesの方ね。Application Service Providerじゃなくて）ではADOを使ってDBアクセスを行っていたが、.netではADO.NETというオブジェクト群を使ってDBアクセスを行う。ADO.NETのコアといえるオブジェクトはDataSetだ。DataSetは一般的なDBMS（SQL ServerとかOracleとか）を利用したデータベースのみならず、XMLファイルなどもデータベースソースとして扱うことができる。概念としてのデータベースを（DBMSから切り離して）高度に抽象化したデータ操作オブジェクトとなっている。

というのがASP.NETの売り文句なんだろう。しかしそれを聞いて、「ふーん、DBMSだけしか扱えなかったADOと違って、.NETではXMLもデータベースとして扱えるように拡張されたんだ」と思ってしまっては罠にはまる。ADO→ADO.NETの変更は拡張ではなく、根本的なポリシー変更（＋おまけ的部分の拡張）だと考えた方が良さそうだ。

というのはなぜかというと、従来のADOでは基本的にデータベース＝DBMSに限定されていた分、ADOを通してDBMSの機能をほぼそのまま利用することができた。しかし、ADO.NET（の中のDataSetを使ったデータ操作）においては、データベースはDBMSとは直接は結びつかない。DBMSのみならずXMLもデータベースソースとして等価に扱えるよう抽象化された結果として、DataSetというのはデータベース上にあるデータそのものではなく、データベース上にあるデータをメモリ上にコピーしたものになってしまった。

「従来のADOを使ったDBアクセスだって（参照系においては）似たようなものだったじゃないか」と思う人もいるかもしれないが、いざとなったらDBMSと直接接続できる（カーソル、トランザクションが使える）ADOと必ずDBの内容をメモリ上にコピーしてからしか扱えないADO.NETとでは、参照系以外のDBアクセスの使い勝手がまったく異なる。今まで調べた限りにおいては、DataSetを使ったDBアクセスにおいて、従来カーソルやトランザクションを使って行っていたような処理を、従来と同程度に手軽に実現する手段は見つけていない（DataAdapter経由でDBMSに直接SQLを発行して、前と同じ内容を前より面倒くさい手段で実現することはできそうだけど）。

ちなみに、データベースの参照系の使い方においては、ADO.NETは非常に便利な拡張をたくさん用意している。従来一般的に使われていた、RecordSetを1行1行ループで回しながら出力していくような処理は、DataSetという形でまとめて表示用コンポーネントに引き渡すことで、ページング処理まで含めて簡単に実現できるようになった。でも、それは確かに実装上の手間を大きく省くかもしれないけれども、クラス仕様の実質としてはおまけ的な意味しか持たないだろう。

という理解の元で、ひとまずお勉強がてらADO.NETを使ってDBアクセスするサンプルをいくつか作ってみたところ、データの参照・更新などを行うプログラムは非常に簡単に作ることができた。しかし、DataSetを使ってお手軽に作ったプログラムにおいては主に更新時のデータ整合性の保証が全然ないように思える。ADO.NETは標準でデータ整合性を保証する仕組みをサポートしないつもりなんだろうか？　それとも俺の知らないどこかで保証する仕組みが動いているのか？　まさかADO.NETは同時更新が頻発する規模のDBアクセスは、標準的に想定外ってわけじゃないよね。

いろいろ調べているうちに、従来のADOを.NET上でADO.NETと（ほんのちょっとだけ）連携させて使う方法を発見したんで、参照系以外の処理は従来のADOを使ってやった方がいいんじゃないだろうか、というのが今のところの結論。でもADOとADO.NETでは互換性がほとんどない（ADOのRecordSetをDataSetにFillできるだけ）んで、両方使うのって重複する（けど書き方が違う）部分が大きくてあほらしい気がするんだよな。実はDBアクセスはすべてADOベースで行いつつ、ADO用の表示を簡略化するためのコンポーネント群を作った方が開発が楽だったりして。DataSetの代わりにRecordSetを食わせるDataGrid（一覧表示用コンポーネント）みたいなものって、結構簡単に作れるんじゃないか？