破損のために登録済みサービスのインスタンスを新しいものに置き換える必要がある場合、これは通常、インスタンスの寿命が長すぎることを示しています。AさんDataContext
がいい例です。ADataContext
はスレッドセーフではないため、それが作成された (Web) リクエストよりも長く存続するべきではありません。Web アプリケーションを扱っていない場合でも、通常、操作するある種のリクエストがあり、各リクエストは独自のDataContext
インスタンスを取得します。
例外が発生した場合は、通常、操作全体をできるだけ早く中止する必要があります。回復して継続しようとすることは、一般的にほとんどの場合悪いことだと考えられています。これは一般的なソフトウェアの原則であり、DI とは関係ありません。ほとんどの場合、何がうまくいかなかったのか正確にはわかりません。続行すると事態が悪化することさえあります。続行しても、アプリケーションがより堅牢になるわけではありません。バグを見つけるのがずっと難しくなるだけです。
簡単に言うDataContext
と、単一のリクエストの存続期間中は最大でも a をキャッシュする必要があり、例外が発生したときにそれを置き換えようとしないでください。リクエストを失敗させてください (そして、バグを見つけて修正するために必要なすべての情報をログに記録してください)。
ASP.NET アプリケーションを実行している場合は、DataContext
インスタンスを として構成できますHttpContextScoped
。