Entity Framework には (少なくとも) 3 つの消費方法があることに注意してください。
- エンティティ クライアントを介したオブジェクト サービスを介したエンティティへの LINQ
- Entity Client を介したオブジェクト サービスを介した Entity SQL
- Entity Client コマンド オブジェクトを使用した Entity SQL (従来の ADO.NET に最も類似)
Entity Client は最終的に、特定の RDBMS の ADO.NET プロバイダーがストア固有の SQL に変換する役割を担う ESQL コマンドの表現を (正規の、データベースに依存しない形式で) 吐き出します。これは、各ストアの優れた ADO.NET プロバイダーを作成するために長年にわたって多くの時間が投資されてきた (そして今後も投資される予定である) ため、適切なモデルです。
Entity Framework は多くのストア、したがって多くの ADO.NET プロバイダーと連携する必要があるため、Entity Client がストアごとに生成するものを簡単に最適化する範囲が狭くなっています (少なくとも、v1 の場合)。LINQ to SQL チームは、解決すべきはるかに小さな問題を抱えていました。「SQL Server でのみ動作する」ため、ストア固有のものをより簡単に実行できました。EF チームは、EF to SQL Server が L2S よりも効率的に TSQL を生成しない場合があることを認識しており、V2 でこれを改善するために取り組んでいます。
興味深いことに、このモデルでは、ストアのエンティティ クライアントと ADO.NET プロバイダーの間に新しい機能を追加できます。これらの「ラッピング プロバイダー」は、ロギング、監査、セキュリティ、キャッシングなどのサービスを追加できます。これは、 http://blogs.msdn.com/efdesign/archive/2008/07/09/transparent-caching-support-in-the-entity-framework.aspxで V2 機能として説明されています。
そのための全体像を見ると、L2S TSQL 生成を Entity Framework のアーキテクチャに何らかの形で後付けしようとすることは、非常に困難であり、実際には制限的であることがわかります。