rider.お品書きサクッと書いて公開して、後でちまちま修正する事がママあります。なんじゃこりゃ?と思ったら、数日してから見て貰えると嬉しいです。「スクラムの実践方法を分かりやすくマンガも交えて解説。前回、.NETにはQueryableクラスがあり、Enumerableクラスの代わりに使用されることで、クエリの条件式をExpressionクラス経由で動的に判断できることを示した。Queryableクラスには、Enumerableクラスで定義されている様々な拡張メソッドが大体同じように定義されている。拡張メソッドの実装方法例を数多く紹介してきた。Queryableクラスの拡張メソッドは、IQueryableを拡張するという違いを除けば、IEnumerableの拡張メソッドと殆ど変わる事は無い。本当にそうだろうか?まず第一に、Funcなどのデリゲートで受けていた条件式は、Expressionクラスで受ける必要があるはずだ。SQLなら、SQL文として成立させなければならない。}}このコード例には2つの問題がある。第一に、IQueryableのバージョンでは、要素数を数える処理がSQL文になっていないことだ。Server等のRDBシステム上で実行されなければならないが、この実装は手元のCLR上でループを実行しているだけで、見ての通りSQL文はどこにも存在しない。第二に、条件式を示すpredictがデリゲートではなくExpressionであるため、直接呼び出すことは出来ない(構文エラーとなる)。Expressionは自分で解析して、式がどのようになっているかを把握しなければならない。このQCountをSQL文で表現したとすると、以下のようになるはずだ。TRUEこの擬似SQL文を見ると更に大きな問題がある事が分かる。Serverからのリモートコールバックで実行されるのか?それはそれは壮大な仕掛けだ。第一、仮にそのように動作したとしても、毎行のWHERE評価の度にコールバック呼び出しが発生する事になる。実際にはどこで実行されるのだろうか?この答えは、「そもそも想定が間違っている」だ。predictはデリゲートではないので、Expressionを自力で評価する必要がある。「評価した式がSQL文に変換可能」であれば、SQL文としてRDBに送信出来ることになる。変換不能であれば、クエリを実行する事は出来ない。それは「実行時例外」という形で表現されることになる。customer;}Regexクラスは、当然.NET固有のクラスだ。Regex.IsMatchに相当するSQL構文は存在しない。このLINQクエリは、SQL文で「表現できない」。表現できないので、実行しようとすると例外が発生する。IQueryableの拡張メソッドは、そのメソッドが意味するところをSQL文に変換出来なければならない。SQL文で表現可能であれば、その意味するところを拡張メソッドに出来る可能性がある、と。WordPress%d人のブロガーが「いいね」をつけました。