ビジュアライザー
奇妙なことに、非常に最初のソリューションはラムダ式自体よりもずっと前に登場し、Visual Studioでのデバッグ情報の表示方法に基づいています。
組み込みのデバッガーは、いわゆるビジュアライザー -ユーザーインターフェイスコンポーネントを使用して、変数またはオブジェクトの値を表示します。 すぐに使用できる5つの異なるビジュアライザーが使用できます。
- テキスト;
- HTML
- XML
- WPFビジュアルコンポーネントツリー
- DataSet、DataView、およびDataTableオブジェクトで表されるデータセット。
それらのいくつかは、値を表示するだけでなく、編集することもできます。 さらに、これは拡張可能なメカニズムであり、開発者は必要な機能を備えたビジュアライザーを作成できます。
したがって、最初のソリューションは、すべてのプロパティを持つオブジェクトのコレクションを表示し、定義済みフィルターのコレクションを使用してフィルタリングルールを構成できるデータテーブルでした。
最も便利な方法は、毎回個別のウィンドウを開いてフィルタリング条件を設定することではないため、検索を続行しました。
エンティティSQL
1年後、試験70-516:TS:Microsoft .NET Framework 4を使用したデータへのアクセスに備えて、以前聞いたことのあるEntity SQLを慎重に研究しました( HQLの経験を除く)。 どんな種類の獣に気付いていない人のために、MSDNから定義を与えます:
Entity SQLは、SQLに似たリポジトリに依存しない言語です。 Entity SQLは、概念モデルに基づいて多数のオブジェクトグラフを照会および管理することを目的としています。
つまり Entity Frameworkでは、フィルター条件を文字列として記述することができます。 例:
using ( var context = new CountriesEntities())
{
var countriesStartWithA = context.Countries.Where( "it.Name LIKE 'A%'" );
}
* This source code was highlighted with Source Code Highlighter .
オブジェクトSQL
既にラムダ式を文字列形式で記述することは、Visual Studioデバッガーの問題を回避する方法であると推測したと思います。 その結果、文字列フィルターを入力として使用するLinq-to-Objectの拡張メソッドが作成されました。 Entity SQLとの類推により、これらはオブジェクトSQLと呼ばれていました。 このようなソリューションの長所と短所は明らかです。 私が指摘したい唯一のものは、代替構文です。 実際には、 ODataプロトコルで使用されるテキスト形式でフィルタリング条件を設定するための別のフォーマットが既にあります。 また、上記のフィルターは次のように書き換えることができます。
using ( var context = new CountriesEntities())
{
var countriesStartWithA = context.Countries.Filter( "$filter=startswith(Name,'A')" );
}
* This source code was highlighted with Source Code Highlighter .
正直なところ、残念ながらVisual Studio 2010のリリースに伴い、ラムダ式のサポートを待っていました。 したがって、作業ツールの不完全さに我慢し、回避策を探す必要があります。
PS:同志のアウトコールドマンが Visual Studio開発チームでこの問題に働きかけていることを願っています