エンティティフレームワークと接続プーリング

最近、.NET 4.0アプリケーションでEntity Framework 4.0の使用を開始しましたが、プールに関連するいくつかのことに興味があります。

1. 私が知っている接続プーリングはADO.NETデータプロバイダーによって管理されています。私の場合は、MS SQLサーバーの場合です。これは、新しいエンティティコンテキスト（ObjectContext）をインスタンス化するときに適用されますnew MyDatabaseModelEntities()か？

2. a）アプリケーションのグローバルエンティティコンテキストを作成する（つまり、1つの静的インスタンス）、またはb）usingブロックを使用して、特定の操作/メソッドごとにエンティティコンテキストを作成および公開することの長所と短所は何ですか。

3. 私が知っておくべき他の推奨事項、ベストプラクティス、または特定のシナリオの一般的なアプローチはありますか？

1. 接続プーリングは、他のADO.NETアプリケーションと同様に処理されます。エンティティ接続では、従来の接続文字列を使用した従来のデータベース接続が引き続き使用されます。使用したくない場合は、接続文字列の接続プールをオフにできると思います。（SQL Server接続プーリング（ADO.NET）の詳細を読む）
2. グローバルコンテキストを使用しないでください。ObjectContextは、アイデンティティマップや作業単位などのいくつかのパターンを内部的に実装しています。グローバルコンテキストの使用による影響は、アプリケーションタイプごとに異なります。
3. Webアプリケーションの場合、リクエストごとに単一のコンテキストを使用します。Webサービスの場合、呼び出しごとに単一のコンテキストを使用します。WinFormsまたはWPFアプリケーションでは、フォームごとまたはプレゼンターごとに単一のコンテキストを使用します。このアプローチを使用できない特別な要件がある場合がありますが、ほとんどの状況ではこれで十分です。

WPF / WinFormアプリケーションの単一オブジェクトコンテキストの影響を知りたい場合は、この記事を確認してください。それはNHibernateセッションについてですが、考え方は同じです。

編集：

EFを使用すると、デフォルトで、各エンティティはコンテキストごとに1回だけロードされます。最初のクエリはエンティティインスタンスを作成し、内部に保存します。同じキーを持つエンティティを必要とする後続のクエリは、この格納されたインスタンスを返します。データストアの値が変更された場合でも、最初のクエリからの値を持つエンティティを受け取ります。これはアイデンティティマップパターンと呼ばれます。オブジェクトコンテキストにエンティティを強制的に再読み込みさせることができますが、単一の共有インスタンスが再読み込みされます。

エンティティに加えられた変更はSaveChanges、コンテキストを呼び出すまで保持されません。複数のエンティティを変更して、一度に保存できます。これは、作業単位パターンと呼ばれます。保存する変更された添付エンティティを選択して言うことはできません。

これらの2つのパターンを組み合わせると、興味深い効果が得られます。アプリケーション全体のエンティティのインスタンスは1つだけです。エンティティへの変更は、変更がまだ永続化（コミット）されていなくても、アプリケーション全体に影響します。ほとんどの場合、これはあなたが望むものではありません。WPFアプリケーションに編集フォームがあるとします。エンティティを操作していて、複雑な編集（値の変更、関連エンティティの追加、他の関連エンティティの削除など）をキャンセルすることにしました。ただし、エンティティは共有コンテキストですでに変更されています。あなたは何をしますか？ヒント：のCancelChangesやUndoChangesについては知りませんObjectContext。

サーバーのシナリオについて説明する必要はないと思います。複数のHTTP要求またはWebサービス呼び出し間で単一のエンティティを共有するだけでは、アプリケーションは役に立たなくなります。どんなリクエストでもトリガーできるSaveChanges間で単一の作業単位を共有しているため、、別のリクエストからの部分的なデータをして保存ます。これには別の問題もあります。コンテキストと、コンテキスト内のエンティティを使用した操作、またはコンテキストで使用されるデータベース接続はスレッドセーフではありません。

読み取り専用アプリケーションの場合でも、アプリケーションにクエリを実行するたびに新しいデータが必要になる可能性があるため、グローバルコンテキストは適切な選択ではありません。

ダニエル・シモンズによると：

メソッドが戻る前に破棄されるように、各サービスメソッドのUsingステートメントで新しいObjectContextインスタンスを作成します。この手順は、サービスのスケーラビリティにとって重要です。これにより、サービスコール間でデータベース接続が開いたままにならず、特定の操作で使用される一時的な状態が、その操作が終了したときにガベージコレクションされます。Entity Frameworkは、アプリドメインで必要なメタデータとその他の情報を自動的にキャッシュし、ADO.NETはデータベース接続をプールするため、毎回コンテキストを再作成するのが迅速な操作です。

これは彼の包括的な記事からここにあります：

http://msdn.microsoft.com/en-us/magazine/ee335715.aspx

このアドバイスはHTTPリクエストにも当てはまるので、ASP.NETにも当てはまると思います。WPFアプリケーションなどのステートフルなファットクライアントアプリケーションが、「共有」コンテキストの唯一のケースである場合があります。

EF6（4,5も）ドキュメントに準拠：https ://msdn.microsoft.com/en-us/data/hh949853#9

9.3リクエストごとのコンテキスト

Entity Frameworkのコンテキストは、最適なパフォーマンスエクスペリエンスを提供するために、短期間のインスタンスとして使用されることを意図しています。コンテキストは短命で破棄されることが期待されているため、非常に軽量で、可能な限りメタデータを再利用するように実装されています。Webシナリオでは、これを念頭に置き、1つの要求の持続時間以上のコンテキストがないことが重要です。同様に、非Webシナリオでは、Entity Frameworkのさまざまなレベルのキャッシュについての理解に基づいて、コンテキストを破棄する必要があります。一般的に言えば、アプリケーションの存続期間を通じてコン​​テキストインスタンスを使用することは避け、スレッドごとのコンテキストや静的コンテキストを使用しないでください。

以下のコードは、オブジェクトを新しいデータベース値で更新するのに役立ちました。Entry（object）.Reload（）コマンドは、オブジェクトにデータベース値を強制的に呼び戻します

GM_MEMBERS member = DatabaseObjectContext.GM_MEMBERS.FirstOrDefault(p => p.Username == username && p.ApplicationName == this.ApplicationName);
DatabaseObjectContext.Entry(member).Reload();