1 つの方法は、さらに式を追加できる何らかのメモリ内オブジェクトとしてクエリを表現することです。たとえば、構成されたオブジェクト階層を使用すると、次のようになります。
var q = Table("Test1").Select("Name");
フィルターを追加して、これをさらに絞り込みます。
q = q.Where("ID= 1");
しかしもちろん、これはあなたが再発明していることを意味しますIQueryable
。その場合は、LINQ を採用し、プロバイダー (LINQ2SQL または LINQ2EF など) を選択することをお勧めします。
もう 1 つの方法は、文字列のアドホック表現を維持することです。
var q = "Select Name from Test1";
しかし、その後、どのようにフィルターを追加しますか? 文字列を解析し、WHERE 句を挿入する必要があります。これは些細なことではありません。すぐに本格的な SQL パーサー ( lex + yaccまたはbison + flex ) と抽象構文ツリーを実装し、これを新しい SQL 文字列としてシリアル化します。結合 (サポートするのはかなり些細なこと)、サブクエリ (厄介)、再帰テーブル式 (痛い) について考え始めると、物事は次第に複雑になります。このサイトを参照して、SQL クエリがどのように複雑になるかを見て、その解析を実装することを想像してみてください。
私が見たプロジェクトの多くは、クエリを何らかの中間形式として表現しようとしました。構造 (フィールドのリスト、テーブル名、WHERE 条件のリスト、ORDER BY 句のリストなど) を作成し、これらのリスト表現に新しいエントリを追加します (新しいフィルタを追加するには、WHERE リストに新しいエントリを追加します)。しかし、振り返ってみると、これらの表現は LINQ が提供するものと比べると見劣りします。確かに、LINQ は全か無かのオファリングであり、コミットするかしないかのどちらかです。しかし、それを再発明しようとしても、問題の複雑さが明らかになるだけです。今日、私は反対側から問題に取り組みます: LINQ から始めて、それを寄せ付けないようにします。プロジェクトのすべてのレイヤーがフィルターを追加する制御不能なクエリ生成ツールの恐ろしいモンスターに成長させないでください。IQueryable
そして、オプティマイザーが解きほぐすことさえできない何かでサーバーを爆撃します。
PS。私が書いた理由 ARELは、この問題全体についての良い読み物です。