また、書いてみようと思う。

LINQ の本を読んでいます。その中で、C# や VB.NET に追加された、ラムダ式、型推論、拡張メソッドといった機能は、LINQ の為に追加された機能で、むやみやたらと使うものではない．．．と、書かれています。

確かに、C# の「型推論」“だけ”が取り上げられたときは、VB の様な「何でも型」が C# に取り入れられるのか！？と、物議を醸し出したように思います。

しかし、実際には、コンパイラが右辺から左辺の型を推論するもので、“コーディングを簡略化する”という説明が、そのときはされていたように思います。

で、実際には、LINQ では、コーディング時にいちいち型を定義しづらい場合があるので、LINQ を実装するために必要な機能だった、ということです。

で、LINQ。（ここから先、オレ理解）これは、データの塊を扱うときに、“どこにあるデータの塊か”ということを、開発者が意識しなくてもいいようにする仕組みです。LINQ to ほにゃららが、どこにあるのかによって最適な形に、コードを展開します。

データベースというと、Oracle, SQL Server, PostgreSQL, MySQL あたりをあげておけばいい？DB2 とか Firebird もあげておく？そんなもんかな？いろいろありまして、SQL99 で標準が決められてはいますが、方言があります。

.NET Framework では、System.Data 名前空間に、いくつかのデータベース用のクラスが用意され、いくつかのインターフェイスが定義されています。この、“いくつかの”ってのがくせ者で、使いにくかったのだけど。

で、接続先ごとに、それら用のクラスを使い、ビジネス ロジックではインターフェイスを使うようにすると、複数のデータベース システムに対応したシステムが作れます。

この方法では、アプリケーション開発者が、SQL のそれぞれの方言を確認し、それぞれにあわせた SQL を組み立て、コーディングします。「ストアード プロシージャでやれ」ってのは、置いておく。

対して LINQ では、アダプター提供者が SQL の方言を吸収するため、開発者はどのターゲットに対しても同じコードを書いておけばよい、ということになります。

確かに、便利です。簡単です。

で、それでいいの？

いえ、問いを変えましょう。「本当に、簡単になったの？」

私は、「いいえ」と思うのです。なぜか。それは、私が「簡単になって欲しい」と思っている対象と、「簡単になる」と言われている対象が違うからです。

LINQ によって、“コーディングは”簡単になりました。しかし、顧客の要望をコードにするところは、簡単にはなっていません。そして、コードを書くことよりも、顧客の要望をコードで表すことのほうが、遙かに難しいと思うのです。

あるいは、この言葉はあまり好きではありませんが、コードを書くことだけに専念する人をコーダーと呼ぶ場合があります。コーダーの仕事は楽になりますが、仕様書を作る人の仕事が楽になるわけではありません。余談：ん～？だからコーダーは安物扱いされるのか？

掲示板などに書き込まれている内容から私が思うのは、仕様書だけを書いている人は、実際に使うものについては無頓着です。何を使おうと、「データベースからデータを参照し、ユーザが編集し、データベースに書き戻す」とだけ書いておけば、自分の仕事は済んだと言わんばかりです一例。それによって、実装者がどれほど苦労しているかも知らずに。。。

で、実装者の方です。これで、本当に簡単になるのでしょうか。

確かに、コードを書くことは軽減されます。しかし、ここで勘違いして欲しくないのは、コードを書くという手作業が軽減されることと、コード化するという頭脳作業が軽減されることは、必ずしも一緒ではない、ということです。

LINQ によって、コード化する手作業は軽減するでしょうが、どのようなデータの取得をしなければならないかという頭脳作業については、軽減されていません。

それどころか、デバッグの時に、どのコードによってどのようなデータが集まってきているのか、わかりにくくなっているかもしれません（実際に動かしたことはないので未確認）。

「簡単になる」のは、いいことなのでしょうか。それはいいことなのでしょう。でも、本当に、簡単になっているのでしょうか。“何を”簡単にしたいのか。そこのところが抜け落ちているような気がします。