2

私は現在、C# でクエリ ビルダーを構築しています。これは、最初に、ローカル マシンでクエリを実行するデータベースを指定するようにユーザーに求めることから始まります。

したがって、このプログラムでは、常に使用されるテーブルを含む多数のデータベースを使用するのではなく、データベースを「プラグイン」することができます。

したがって、クエリ ビルダーで SQL ステートメントを生成するには、SQL ステートメントを文字列の形式で出力して実行する方が理にかなっていますか、それとも Entity Framework を使用できますか? 私はEntity Frameworkの経験がありませんが、私が理解できることから、テーブルとスキーマを認識している静的データベースがある場合は、EFを利用する方が理にかなっています-実行時にユーザーによって指定されている可能性のあるデータベース-時間。

私は現在、SQL ステートメントを扱ってきました。つまり、クエリ ビルダーとのユーザーのやり取りは、アプリケーションによって生成された文字列ベースの SQL ステートメントを文字通り実行します。Entity Framework に切り替えることは可能ですか、またはその価値はありますか?

4

2 に答える 2

2

EF を使用した私の経験から、クエリを動的に生成する場合は、SQL 文字列を使用することをお勧めします。

未知のスキーマをクエリするために EF を使用できる唯一の方法は、リフレクションによってエンティティを生成することです。これは非常に多くの作業になります。そして、それがうまくいくかどうかはわかりません。また、EF を使用することによるすべてのメリットが失われます。

したがって、これが事実である場合は、いいえ。

于 2012-11-12T17:10:40.057 に答える
1

このシナリオでは、Entity Framework には利点がありません。実は厳しく制限しています。

式ツリーを IQuerable として取り、必要な並べ替えを適用する汎用の SortHelper、PagerHelper、FilterHelper などを作成することができます。この種の汎用プログラミングは、SQL インジェクションを回避できるので優れています。

ただし、クエリ ジェネレーターに Entity Framework を使用する場合は、リフレクションを使用して Entity Data Model を生成する必要があります。さらに、制限のない select ステートメントの実行方法を決定する必要があります。さらに、Entity Framework がクエリを表現および評価する方法に縛られますが、これはバージョン 5.0 の ORM の場合ほど堅牢ではありません! たとえば、適切な SQL を生成したい場合は、右結合を表す良い方法はなく、常に左結合として表す必要があります。もう 1 つの制限は、プロジェクションを作成する場合、匿名クラスを生成する必要があることです。.NET にはメモリから型をアンロードする適切な方法がなく、AppDomain で生成したすべての型は、AppDomain がアンロードされるまでメモリに保持されます。これが、F# 3.0 が F# 型プロバイダー API に型消去を使用する理由です。

また、Entity Framework は、SAT の解決のように、式を変換できるかどうかを判断するための本格的な分析を行いません。

私は、あなたが説明している正確なアプリケーションを構築してから、実際の経験に基づいて答えています。このアプリケーションにより、ビジネス アナリストはクエリを視覚的に記述し、クエリをまとめて作成することができました。

とはいえ、Entity Framework の設計語彙を勉強することをお勧めします。私は Entity Framework を使用していませんが、非常によく似た語彙を使用するようになりました。たとえば、ナビゲーション プロパティです。プロパティとは呼びません。オブジェクト クエリ言語を使用する人にとってはオブジェクト指向の抽象化であり、ビジュアル クエリ言語では意味がないからです。私はそれらをパスと呼んでいます。しかし、Include() と同様に、左結合を意味する Any() 演算子が好きです。これらの小さなモデリングのアイデアは、私にとって価値がありました。

于 2013-04-24T03:34:41.067 に答える