連載：［完全版］究極のC#プログラミング Chapter17　LINQ to SQL 川俣 晶 2010/04/14
Page1 Page2 Page3 Page4 Page5 Page6

17.3 LINQ to SQLという突破口

　以上は、筆者の過去のいくつかの経験を誇張してまとめ直したものである。ただし、筆者の場合、A君よりはSQL Serverについての利用経験や知識がある。たとえば、SQL Serverのデータベースを参照するデモプログラムなどは、昔からときどき作成している。だから、筆者はA君ほど絶望はしていない。

　しかし、使おうとすると膨大なドキュメントの迷宮の中に迷いやすいというデメリットがあると感じるのは事実である。SQL Serverとはそれ専門で扱っている技術者にはなんということもないあたりまえの存在なのだろうが、たまに少しだけ使おうとする技術者にはハードルが高すぎる感がある。

　……とこれまでは思っていた。

　しかし、この本書を書くために「LINQ to SQL」を試したところ、そのような認識がすでに過去のものであったことを思い知らされた。Visual Studio 2008とC# 3.0、そしてLINQを使えば、A君は絶望する必要はなかったのだ。それどころか、ちょっとしたデータの保管場所として、SQL Serverを気楽に使用できるほど手軽になったといってもよい。

　なぜそこまでいえるのか？ その理由の一部はLINQ to SQLにあるのだが、それは理由のすべてではない。むしろ、LINQ to SQLを成立させるために実装された「O/Rマッピング」こそが、C#プログラマーにとってのSQL Serverのハードルを劇的に下げる効能を持つといったほうが正しいだろう。

　なお、マイクロソフトのドキュメントでは「O/Rデザイナ」という用語は使われているが、「O/Rマッピング」という用語は使われていない。しかし、ここでは説明の便宜上、一般的なO/Rマッピングという言葉を使うことにする。

　では、O/Rマッピングとは何だろうか？ これは、RDBとオブジェクトの橋渡しを行う機能であり、実際にデータが格納されているのはRDBであるにもかかわらず、プログラマーはそれをC#のオブジェクトとして扱えるのである。つまり、プログラマーはSQLの構文を知らずとも、オブジェクトの使い方だけ知っていればコーディング可能となるわけである。

　しかし、O/Rマッピングさえ実現できればそれでいいという話ではない。たとえば、任意の設計を行ったクラスをRDBに格納するためにマッピングを行う技術も世の中には存在する。そのような仕掛けがあれば、RDBに関する知識を完全に排除して開発を行うことができて効率が上がりそうだが、実際は必ずしもそうではない。

　なぜなら、オブジェクト指向にとって都合の良い構造が、RDBにとっても都合が良いとは限らないからだ。効率的なクエリを実行するためには、どうしてもRDBにとって効率の良いデータベース設計を行う必要がある。そして、効率的なクエリの必要がなければ最初からRDBを持ち出す必要がない以上、それはたいていの場合、必須の要求となる。

　LINQ to SQLが持つO/Rマッピングは、これとは逆の方向でマッピングを行う。つまり、既存のRDBのデータベースに対して、それをオブジェクト経由でアクセスするレイヤを生成してくれるのである。これは万能ではないが、あらかじめ設計され、構築されたRDBを検索し、更新するようなプログラムなら、C#とマッピングオブジェクトの知識だけで記述できる。SQLの細かい構文を学ばずとも、コーディング可能となるのだ。

　もしそれだけでは効率的なクエリが実現できない場合は、後述の方法で実際にどのようなSQLのクエリが生成されているかを調べ、O/Rマッピングを使わずに、直接SQL文を実行させることもできる。LINQ to SQLの世界にあるO/Rマッピングは、世界を支える唯一の支柱ではなく、いくつもの支柱の1つにすぎない。昇りやすい支柱が1つ増えたことで、気軽に訪問しやすくなったというだけの話である。

INDEX
	［完全版］究極のC#プログラミング
	Chapter17　LINQ to SQL
	1．17.1 効率的に列挙可能にするという問題
	2．17.2 SQL Serverのワナ
	3．17.3 LINQ to SQLという突破口
	4．17.4 LINQ to SQLのサンプル
	5．17.5 LINQ to SQLとメソッド構文
	6．17.6 LINQ to SQLのまとめ／練習問題

　

「［完全版］究極のC#プログラミング」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）