悩ましいRDBMSの利用時のアーキテクチャの選択

唐突ですが、C#(というか.netのアプリケーション）で、RDBMSを利用するのは、.netの登場から10年以上たった今でもどうするのが正解か？いまだに難しい問題だなぁと思っています。

探してみるとRDBMSと.netの間に入る、よさそうなミドルウェアもなくはないんだけど、チームでの開発だとライセンスのコストや習熟にかかるコストが読みづらく、正直選択がためらわれる。

で、.netの標準の仕組みでデータベースアクセスをしようとすると、今なら以下のいずれかを選択することになりますね(新しい順)。

• Entity Framework
• LINQ to SQL
• 型付きデータセット/形無しデータセット
• 生ADO.net (DbConnection+DbCommand+DbDataReader)

個人的な感想を言うと、どれも一長一短なのです。

• Entity Framework
• 物理層のRDBMSを抽象化した、論理層に対する操作を行う。論理層への操作(LINQを使った処理)が物理層(SELECT等のSQLコマンド)にマッピングされる動作はすばらしいと思う。
• が、特定のフィールドのみ更新したい場合ないど、UPDATEとの相性がいまいち。
• それと、物理層への操作は基本的に排する方針のようで、インデックスやらトリガやらビューやらはどう組み込んでいいものやら。要は、RDBMSでお気楽にできる処理が、簡単じゃなかったりすることがしばしば起こる。
• インデックスとかを取り込みにくいので、Webアプリのように徐々にレコード数が増えていくものであれば、DBのスキーマが定まった後に、必要に応じてインデックスを追加していくのはイケルかと思う。でも、最初からデータ移行で数十万レコードを考慮しないとならんようなケースでは、インデックスやトリガやビュー等を最初から考慮した設計を行いたいんだけど、…なんかすごくやりづらい。
• そもそも、習熟した人がほとんどいない。
• LINQ to SQL
• SQLServer以外が選択肢にならない。
• 今後のメンテナンス/機能追加が期待できない。
• 型付きデータセット
• きらい。
• …(それ以外の理由が必要？)
• LINQを意識した作りになっていない。
• 自動で付加されるクラス名に、すごい名前付けてくれちゃったり。おかげでよほどベテランさんが意識してコードを書かないと読みにくいのなんの。
• Visual Studioのデザイナ(UI)の出来がイマイチ。よくわからない挙動にイラッとすることも度々。イヤになるほど遅いし。ちょっと複雑なSELECT文だとどうにもエラーになっちゃったり。
• 特定のフィールドのみを出力するSELECTや、複数テーブルをJOINしたSELECTとかは別のクラスにするの？一つのクラスでSELECTごとに埋まる項目が変わるの？クラスを呼び出す側はメソッドによってデータが入ってたり無かったりするのかな？どうもこう、どう注意して作っても統一性が取れなくて。
• 形無しデータセット
• 当然、LINQを意識した作りになっていない。
• フィールド名によるインデクサを多用せざるを得ないため、文字列リテラルが大発生。文字列リテラルに間違いがあると実行時のエラーとなってしまうのでバグの元が山盛りある状態に。
• さらにインデクサで取得してもすべて形無し(object)になってしまうので、キャストやらコンバータやら、本来処理したいもの以外のコードでソースが埋め尽くされる。
• そこに持ってきて、DBNullがオブジェクトのNULLにマップしてくれないので、NULLチェックによる処理もソースを汚し倒してくれる。
• これはもう誰が書いてもそうなる。
• 生ADO.net (DbConnection+DbCommand+DbDataReader)
• イイ言い方をすれば「由緒正しい」。それってつまり「古臭い」。
• それぞれ構築と廃棄を意識して作る必要がある。usingによるネストが大発生。using使わなかったりするとそれはそれで悲しいコードになりがち。

と、まぁ、悩むことこの上ない。そんなこんなで僕ならどうするか。次のエントリで書いてみたいと思います。(解決にはなりません。あんまり期待しないでほしいっす。)