2009-09-01 10 views

答えて

9

LINQ to Entitiesでは、データベースのすべての機能にアクセスすることはできません。データベースへの「到達」が可能な場合は、最初にそれらを取り除くか、LINQ to Entitiesシステムがクエリに対して行う恐ろしい選択を改善するために、高度なクエリに必要な場合があります。

私はLINQ to Entitiesが最初に到達したツールであると信じています。パフォーマンスが問題になったり、さらに複雑なものがある場合は、その問題をストアドプロシージャにカプセル化して呼び出します。最近では、文字列がクエリの基礎として使用される理由はありません。

2

ESQLでは、LINQ-Any-Anyでサポートされていないwhere句に対して照合を選択できます。これは本当に便利です。 ESQLでは、型が互いに継承するときに返される正確な型を指定することもできます(LINQのOfTypeでは、特定の型とサブタイプのインスタンスを返します)。それを超えて、私はそれを使う大きな理由を考えることができません。文字列でクエリを作成することは時折便利ですが、DynamicQuery/Dynamic LINQは、これが必要な非常にまれなケースでは一般的に十分です。

ESQLの "本物の"目的は "それはLINQに先行している"と(おそらく皮肉なことに)私は思う。

非最適なクエリを修正するGodekeの点に関しては、LINQの式を変更することで修正できなかったものをまだ見ていません。 ESQLとL2Eの両方がCCTとして終わるので、SQL生成パイプラインは同じです。

+0

準最適なクエリについての私の主張は、LINQ to EntitiesではできないものをTSQLで実行できることです。いくつかの例については、「パラメータスニッフィングエンティティ」を使ってGoogleを見てください(あるいは、修正がある場合は、他の人に助けてもらいましょう)。私が信頼できると感じた一般的な回避策はT-SQLスニッフィングエラーを回避します。 – Godeke

+0

T-SQL、はい。 ESQL、ほとんどの場合、いいえ。問題は、* T * -SQLではなく、LINQ vs. * E * SQLでした。 –

+0

は略語を説明していますpls – alchemical

関連する問題