DbContextオブジェクトは、スレッドセーフでない性質のため、SingleInstanceではなくInstancePerHttpRequestとして作成する必要があることを読みました。これは、requet間で大量のリソースを消費し、意味をなさない可能性があるためです。しかし、私はDbContextインスタンスを使用するリポジトリオブジェクトを使用しています。それらをInstancePerHttpRequestにするか、SingleInstanceにして、DependencyResolverを使用して現在のDbContextを取得する必要があります。
Autofac（またはその他のDI）、DbContext、リポジトリ、およびサービスベースのWebアプリケーションにとって、最適なオブジェクト作成設計は何でしょうか？
別の質問ですが、Webリクエストごとにリポジトリまたはサービスごとに異なるDbContextオブジェクトを作成するのにどれくらいの費用がかかりますか（リクエスト内の10〜15個など）？
DbContextはインスタンス化するのに非常に安価なので、新しいものを取得するのにかかる時間についてあまり心配する必要はありません。
DbContextのスコーピングで私が抱えている問題は、スレッドセーフではなく、クエリの分離です。誰でも変更の保存を呼び出してオブジェクトグラフ全体をデータベースにコミットできるため、特定の変更を含むコンテキストでのみ呼び出すようにします。
DbContextについて理解するもう1つの重要な点は、追跡するアイテムが増えるほどパフォーマンスが低下することです。これは、シングルトンでバインドすると、かなり深刻なパフォーマンスの問題が発生する可能性があることを意味します。（これを回避する方法はありますが、これに関する私の投稿をここで参照することを知っておくのは本当に良いことです）
私の個人的なWebアプリの好みは、HttpRequestのスコープ内でコンテキストとリポジトリの両方をバインドすることです。これは、現在のリクエストスレッドのみが変更を保存できることを意味し、追跡する可能性のあるアイテムの量も制限します。
申し訳ありませんが、私の用語の一部は、おそらく私自身がninjectmanとしてautofacと一致しません:)
DbContextは作業単位であるため、SingleInstanceスコープには適していません。そのように扱ってください。リクエストがUoWに直接マッピングされることもありますが、必ずしもそうとは限りません。リクエストをスコープする前に、これを考慮してください。
DbContextはインスタンス化するのに安価なので、各サービスが独自のインスタンスを取得するように設計します。問題が発生しない限り、インスタンス化されたDbContextの数までさかのぼることができますが、リクエストごとに10〜15で問題ありません。他の何かは私には時期尚早の最適化のようなにおいがします。
私は主にStructureMapを使用しているため、DIにとらわれないようにしました。