Entity Framework を使用する場合、ESQL は Linq to Entities よりも優れたパフォーマンスを発揮しますか?
私は Linq to Entities を使用したいと思っています (主に強力な型チェックのため) が、他のチーム メンバーの何人かは ESQL を使用する理由としてパフォーマンスを挙げています。いずれかの方法を使用することの長所/短所を完全に把握したいと思います。
Entity Framework を使用する場合、ESQL は Linq to Entities よりも優れたパフォーマンスを発揮しますか?
私は Linq to Entities を使用したいと思っています (主に強力な型チェックのため) が、他のチーム メンバーの何人かは ESQL を使用する理由としてパフォーマンスを挙げています。いずれかの方法を使用することの長所/短所を完全に把握したいと思います。
最も明白な違いは次のとおりです。
Linq to Entities は、優れたクエリ理解構文を含む、厳密に型指定されたコードです。「from」が「select」の前にあるという事実により、IntelliSense が役立ちます。
Entity SQL は、SELECT ステートメントが FROM ステートメントの前にある、より使い慣れた SQL のような構文を使用して、従来の文字列ベースのクエリを使用します。eSQL は文字列ベースであるため、実行時に文字列操作を使用して動的クエリを従来の方法で構成できます。
あまり目立たない主な違いは次のとおりです。
Linq to Entities を使用すると、「select new{... }」構文を使用して、形状を変更したり、クエリの結果を必要な形状に「投影」したりできます。C# 3.0 の新しい匿名型では、これが可能になりました。
常に ObjectQuery<T> を返す必要があるため、Entity SQL を使用してプロジェクションを行うことはできません。一部のシナリオでは、ObjectQuery<object> を使用できますが、.Select が常に ObjectQuery<DbDataRecord> を返すという事実を回避する必要があります。以下のコードを参照してください...
ObjectQuery<DbDataRecord> query = DynamicQuery(context,
"Products",
"it.ProductName = 'Chai'",
"it.ProductName, it.QuantityPerUnit");
public static ObjectQuery<DbDataRecord> DynamicQuery(MyContext context, string root, string selection, string projection)
{
ObjectQuery<object> rootQuery = context.CreateQuery<object>(root);
ObjectQuery<object> filteredQuery = rootQuery.Where(selection);
ObjectQuery<DbDataRecord> result = filteredQuery.Select(projection);
return result;
}
チーム メンバーの 1 人がこことここで詳細に説明しているその他のより微妙な違いがあります。
ESQL は、特に悪質な SQL を生成することもあります。継承されたクラスを使用するようなクエリの問題を追跡する必要があり、4 行の非常に小さな ESQL が 100000 文字のモンスター SQL ステートメントに変換されていることがわかりました。
Linq で同じことを行ったところ、コンパイルされたコードははるかに扱いやすくなりました。20 行の SQL としましょう。
さらに、他の人が言及したように、Linq は厳密に型指定されていますが、編集して続行する機能なしでデバッグするのは非常に面倒です。
広告
Entity-SQL (eSQL) を使用すると、動的クエリなどを LINQ to Entities よりも簡単に実行できます。ただし、eSQL を必要とするシナリオがない場合、LINQ よりも eSQL に依存することを躊躇します。これは、保守がはるかに困難になるためです (たとえば、コンパイル時のチェックが不要になるなど)。
LINQ を使用すると、クエリもプリコンパイルできるため、パフォーマンスが向上する可能性があると思います。Rico Marianiは、しばらく前にLINQ のパフォーマンスについてブログを書き、コンパイルされたクエリについて説明しています。
ここでパフォーマンスの比較を示す素晴らしいグラフ: Entity Framework Performance Explored ESQL と Entities の間に見られる大きな違いはありませんが、直接クエリよりもエンティティを使用する場合の全体的な違いは重要です
Entity Framework は 2 層のオブジェクト マッピングを使用し (LINQ to SQL の単一層と比較して)、追加のマッピングにはパフォーマンス コストがかかります。少なくとも EF バージョン 1 では、モデリングおよび ORM マッピング機能がそのコストを正当化できる場合にのみ、アプリケーション設計者は Entity Framework を選択する必要があります。
コンパイル時のチェックでカバーできるコードが多ければ多いほど、パフォーマンスよりも重視したい点です。この段階では、パフォーマンスのためだけでなく、(現時点では) できることがはるかに柔軟であるため、おそらく ESQL に傾倒するでしょう。本当に必要な機能を備えていないテクノロジ スタックを使用することほど悪いことはありません。
エンティティ フレームワークは、カスタム プロパティ、カスタム クエリ (実際にパフォーマンスを調整する必要がある場合) などをサポートしておらず、linq-to-sql と同じように機能しません (つまり、エンティティで単に機能しない機能があります)。フレームワーク)。
Entity Framework についての私の個人的な印象は、多くの可能性があるということですが、現在の状態で運用環境で使用するには、実装が少し「硬直的」である可能性があります。
直接クエリの場合はエンティティへの linq を使用し、動的クエリの場合は ESQL を使用しています。たぶん答えはどちらか/またはではなく、かつ/またです。