C#勉強中 C# 3.0 入門 最終回

C# 3.0 入門の続き

最終回 LINQ to SQL／落ち穂拾い

SQL Serverのワナ

はまあ、誇張しすぎですが、SQLが言語に統合されていないことによって、実行時までエラーが判らないというのは実際面倒な点です。最近はチェック機能の強力な開発環境に慣れてしまっているため、その場でエラーチェックがかかるのが当たり前になっていますから、そんな中で実行時までチェックできない、というのはどうよ、といいたくなります。

LINQ to SQLという突破口 

この観点からのLINQの有難味が普通なら最初に来るところなんですがね。最後になってやっと出てきました。ここで話題になっていて初めて気づいたのですが、LINQ to SQLの実現には、低レベルでのORマッピング（MS用語ではORデザイナ、なんでMSは一々普通と違う用語を使いたがるのでしょうか）が必要になっているのですね。言語レベルでSQLのデータにアクセスできるということは、バックエンドでSQLからオブジェクトへの自動的なマッピングが行なわれているということになります。私もORマッピングについては懐疑的（中途半端な自動処理はかえって面倒）でしたが、このようなバックエンドとしてのORマッピングは結構便利かも知れません。これによってSQLへのアクセスが単純化されるのは何よりです。最終的なアプリケーション向けのオブジェクトデザインは、その上で行なえばいいわけですからね。

LINQ to SQLのサンプル

ここの部分を自前で試してみるために、自前のDBテーブルを作成するところから始めたために恐ろしく時間が掛かってしまいました。最初から手に入るNothwindDBでも使えば良かったのかもしれませんが、手間を掛けただけの達成感は得られました。おかげで LINQ to SQL どんとこい、といった気分に浸れます。まあ、実際にはまだ触っていない部分が多数あるわけですが。

LINQ to SQLとメソッド構文

確かに、クエリー式でクエリーがリモートのDBMSで実行されますよ、というのはなんとなく判ってもメソッド構文で書かれると一見納得できませんね。普通のコードの一部が別のところで実行される、ということですからね。しかし、式をデータとして扱える、というのはこういう場合に効果発揮するものです。最近の言語ではこの手の機能が流行りですね。自己改変コード扱いされていたものですが。

LINQ to SQLのまとめ

アセンブラに対する(初期の)C言語のような比較で LINQ to SQL の便利さを説明していますが、いいたいことは判らなくもないですが、あまりうまい比喩ではないでしょう。この解説記事の流れからすると、頭の方で書かれていたように、LINQによって、データの集合（DB限定でなく）に対する演算が統合されたことと、LINQ to SQL によって、DBへの操作も言語/IDEに統合された、点の方を大きく評価したいですね。今までの方法は、統合とか称されていても名ばかりで、実際には別々のものを見た目だけ一緒に書けるようになっていただけでした。LINQなら本当に（IDEのシンタックスチェックレベルから）統合されているわけで、これは大きな利点だと思います。

また、DBにアクセスする人が皆DBの専門家ではないことを考えると、特にBI系のアプリなんかでは、LINQは効果が大きいのではないでしょうか？BI系なんかで、DBのデータは参照が基本、処理をSQLだけで記述するのはキツイ、といった状況ではLINQによって普通の言語系にDB参照が組み込めるというのはすごく便利なポイントだと思います。

そういえば、LL系の言語でこのあたりのDBアクセスの統合ってどうなっているのか、時間がとれたらちょっと調べてみたいですね。

さて、これでC# 3.0入門は読み終わりました。が、このシリーズ読んでいるうちに新しい連載「究極のC#プログラミング」が始まってしまっています。流れとしては次はこちらでしょうね。