私はエンティティフレームワークが初めてです。いくつかのスクリーンキャストI've been watchingは、結果セットが変更された状態でメモリに保持されていることを示します。これは、メモリを大量に使用する可能性があるようです。エンティティフレームワークを使用すると、DataSetのようにメモリに大きな負担がかかりますか？
これは、EFがASP.NET開発に適していないことを意味しますか？エンティティフレームワークはSqlDataReaderに似たメモリ効率的なパターンを持っていますか？
"エンティティフレームワークは、SqlDataReaderに似たメモリ効率のよいパターンを持っていますか？"
いいえ、EFは、DataSetやDataRelationsなどと同様に、RAM内のオブジェクトの完全なコピーを作成しますが、代わりにオブジェクトに保持します。また、各オブジェクトの変更（Changesets）のコピーを保持する必要があります。これらの変更のそれぞれは、変更をサブミットした場合にデータベースを更新するSQLとして構築されます。
SqlDataReaderは、一度に1つの行を取得するための、前方のみの軽量リーダーです。 EFはクエリに対するすべての回答を、その上に変更の追跡を伴うオブジェクトコレクションに読み込んでいます。
あなたのアプリに適していますか？知りません。できるだけ早くRAMを最小限に抑える必要がある場合は、ADO.NETが唯一の方法です。どれADO.NETの上に置か抽象化のオーバーヘッドを追加するために起こっている、メモリなど
クエリ結果をオブジェクトとして列挙すると、DbDataReaderが実際に使用され、オブジェクトがその場で作成されるため、実際のEntityObjectとしてメモリ内に1行しか存在しないようです。 EntityClient Providerを使用してDataReaderレベルのデータにアクセスすることもできますが、最適なパフォーマンスが心配されている場合は、通常のADO.NETに準拠する必要があります。
私は、合理的にトラフィックの多いサイト（250kページビューで1日に12,000〜20,000人のユニークビジター）でメモリやパフォーマンスの問題がなく、Entity Frameworkを使用しました。
また、Entity Framework 4.0を待つか、プレリリース版を使用することをお勧めします。これには多くの改善があり、そのうちの1つはPOCO（Plain Old CLR Objects）のサポートです。
EFは（あなたが正しくADO.netを使用すると仮定して）直接ADO.netを使用するよりも多くのメモリを使用します
ことを言いました私たちはメモリ問題のない大規模なASP.netプロジェクトでEFを使用しました。
私が考えることができる唯一の状況は、大きなバイナリオブジェクトを処理していて、それらをメモリにロードする代わりにストリーミングする場合です。