Entity Framework はリフレクションを使用してパフォーマンスを低下させますか?

はい、他の多くの ORM (NHibernate) や便利なフレームワーク (DI ツール) と同様です。例:WPF Reflection なしでは機能しません。

Reflection を使用した場合のパフォーマンスへの影響は、.NET 1.0 からの過去 10 年間で (改善はありましたが) あまり変わっていませんが、ハードウェアの高速化と可読性への一般的な傾向により、現在ではあまり問題になりません。

主なパフォーマンス ヒットは、反射別名バインディングの時点であることに注意してください。 型メタデータを xxxInfo に読み込みます (MethodInfo など) ) これはアプリケーションの起動時に発生します。

呼び出し中 Reflected メソッドは明らかに遅くなりますが、あまり問題にはなりません。

更新

Reflector を使用して EF のソース コードを調べたところ、Reflection が多用されていることが確認できました。


問題 1 の回答:

Foo.Designer.cs を調べることで、EF の出力を正確に確認できます。 生成されるファイル。結果のコンテナーはリフレクションを使用していませんが、ジェネリックを多用していることがわかります。

Entity Framework が確実にリフレクションを使用する場所は次のとおりです。

<オール>
  • Expression<T> インターフェイスは、SQL ステートメントの作成に使用されます。 System.Linq の拡張メソッド System.Reflection の型を使用する式ツリーのアイデアに基づいています。 関数呼び出しや型などを表す
  • 次のようなストアド プロシージャを使用する場合:db.ExecuteStoreQuery<TEntity>("GetWorkOrderList @p0, @p1", ...) 、Entity Frameworkはエンティティにデータを入力する必要があり、少なくとも TEntity を確認する必要があります 提供されたタイプが追跡されます。
  • 問題 2 の回答:

    確かに、クエリの見た目が奇妙に見えることがよくありますが、効率が悪いわけではありません。 実際のクエリ プランを備えたクエリを考え出すのは難しいでしょう。

    その上、確かにストアド プロシージャを使用できます。 、またはクエリと作成、更新、および削除のためのエンティティ フレームワークを備えたインライン SQL です。

    余談:

    どこでもリフレクションを使用し、ストアド プロシージャを使用できなかったとしても、それが使用しない理由になるのでしょうか?同僚に証明してもらう必要があると思います .


    生成された EF クエリはストアド プロシージャよりも効率が悪いという問題 2 についてコメントできます。

    基本的にはい、生成されたクエリが混乱していて、調整が必要な場合があります。これを修正するのに役立つ多くのツール、SQL プロファイラー、LinqPad などがあります。しかし、最終的には、生成されたクエリはがらくたのように見えるかもしれませんが、通常はすばやく実行されます.

    はい、EFエンティティをプロシージャにマップできます。これは可能であり、生成された厄介な EF クエリの一部を制御できます。次に、ビューをエンティティにマップして、ビューがデータを選択する方法を制御することもできます。

    リソースについては考えられませんが、これを言わなければなりません。 EF ストアド プロシージャと SQL ストアド プロシージャの使用の比較は、リンゴとオレンジです。 EF は、データベースをコードに直接マッピングする堅牢な方法を提供します。これを LINQ to Entity クエリと組み合わせると、開発者はコードをすばやく作成できます。 EF は ORM ですが、SQL ストア プロシージャはそうではありません。