私はAutoFacを使用しており、カスタムキャッシングの実装をしています。キャッシュされた実装のタイプを登録するとき、私はキャッシングサービスをSingleInstance（）として設定しました。ただし、これにより、2番目の同時要求がクローズされた接続にアクセスしようとするため、EFを使用したデータベース接続の問題が表示されます。.NETキャッシングwith AutoFac
Builder.RegisterType<MyCachingDataService>().As<IMyCachingDataService>().SingelInstance();
そこで我々は（SingleInstanceを削除）し、それが今の問題は、それがパフォーマンスが低いその方法、私たちは呼び出しごとにインスタンスをすれば、それは一種のキャッシングの目的に反していることで、コールごとのインスタンスをデフォルトで作りました。
これを回避する方法は何ですか、私は間違っています。
デタッチエンティティをキャッシュする必要があります。この方法では、データベースにアクセスしようとしません。例えば
context.MyEntities.AsNoTracking().Where(...).ToList();
詳細はこちらを参照してください。
How do I detach objects in Entity Framework Code First?
このコードは、使用しているEFのバージョンによって異なります。
私はあなたが彼が尋ねたキャッシングを誤解したと思います。彼は一般的なキャッシュに文脈上のキャッシュではないと尋ねる。 1つのサービスは何らかの結果を尋ね、彼はこのデータをメモリ（またはredis vs）に保存し、同じ質問のためにdbには行かず、10分と言う。 –
@ErkanDemirel EFコンテキストからエンティティを切り離したり、EFコンテキストが破棄された後でナビゲーションプロパティを使用しようとしたりしない限り、メモリ内にあるかHttpContextキャッシュを使用していても、EFエンティティがどのようにキャッシュされるかは関係ありません。例外が発生します。 – Mick
まず、dbcontextはシングルトンであってはなりません。しかし、シングルトンにdbcontextがある場合は、シングルトンになります。あなたはシングルトンのDBコンテキストではありません。
問題を解決するには、Factoryを使用する必要があります。自分で工場を作ることができます。 dbcontextに問い合わせるたびに、最初にファクトリに問い合わせると、dbcontext（dbコンテキストの存続期間に関連する）が返されます。
したがって、キャッシュとファクトリはシングルトンになりますが、dbcontextではなくなります。
オートファクトには自動生成された工場があります。
を使用することができますしかし、私はあなたのキャッシュが dbcontext必要はありません示唆しています。あなたのサービス（または何でも）が最初にキャッシュを要求します。結果がなければ、dbに問い合わせて結果を取得し、キャッシュに保存する必要があります。キャッシュはdbの責任を負いません。キャッシュは、キーによるメモリへの結果の保存と、キーによるメモリからの結果の返却を担当する必要があります。
Aspect-Oriented Programmingを使用すると、メソッドごとにキャッシュシステムを実装できます。これはクリーンなコードに適しています。チェックPostsharp
これはオートファックとは関係ありません。また、使用しているEFのバージョンを指定して、コードを投稿してください。 – Mick
今質問を更新しました。私の接続問題とキャッシュされた実装オブジェクトの性質のため、AutoFacだと思いました。 – Immortal
この問題をAutofacなしで複製できます。エンティティを静的メンバーに設定して再利用するだけで、同じ問題が発生します。その後廃棄されたコンテキストでロードされたエンティティで、未使用のナビゲーションプロパティを使用しようとすると、例外がスローされます。 – Mick