私は現在、30分ごとに実行されるスレッドを作成し、基準を満たすいくつかのエンティティのいくつかのフィールドを更新するWindowsサービスを構築しています(将来的には、他のことを行うためにさらにスレッドを追加したいと考えています。 24 時間、毎週 1 回など）。サービスは、Web アプリケーションで既に使用されており、Ninject を使用して (DbContext と共に) 挿入されたサービスを使用してデータを取得および更新します。これはすべて、InRequestScope() バインディングを使用して正常に機能します。
ただし、Windows サービスを使用してこれにアプローチする最善の方法について考えてきました。基本的に、サービスが開始されてスレッドが作成されると、サービスは (30 分ごとのスリープを除いて) 継続的に実行され、Windows サービスが停止するかプロセスが終了した場合にのみ停止します。私の最初の考えは、Ninject の InThreadScope() オプションを使用して DbContext とサービスを注入することでした。そのため、スレッドごとに DbContext を用意します。しかし、これほど長い有効期間を持つ DbContext を持つことは、一般的に良い習慣でしょうか? この DbContext は破棄されずに何週間もそこに座っている可能性があります-そして、これはあまり良い考えではないのではないかと私は密かに疑っています(メモリリークなど)。
しかし、そうでない場合、このシナリオを処理する最善の方法は何ですか。スレッドが実行されるたびに新しい DbContext を作成できますが、Ninject バインディングをどのように設定すればよいでしょうか? 現在、それらは次のように定義されています。
Bind<IDbContext>().To<EnterpriseDbContext>().InThreadScope();
Bind<IUserRepository>().To<UserRepository>().InThreadScope();
// Etc
したがって、スレッド内に新しいものを作成するためにこれをどのように構造化するかは完全にはわかりません。InTransientScope() を確認しましたが、これによりサービスが異なるバージョンのコンテキストを使用するため、変更が保存されません。
これは非常に一般的なシナリオのように思われるため、他の人の意見を聞くことができれば幸いです。