繰り返されるマルチコンテキスト タスクを処理するための静的クラス ライブラリがあります。静的クラスのメンバーとして EF db コンテキストを作成するのは悪い習慣ですか?
DB コンテキストは、何らかの理由で破棄されることを意図しています。それらを頻繁に破棄すると、接続プールが「流れ」続け、おそらく（ここでは推測していますが）テーブルがロックされたままにならないことが保証されます。
では、静的クラスに db コンテキストを持つことで問題が発生しているのでしょうか、それとも考えすぎなのでしょうか?
IMOこれは間違いなくあなたがやりたいことではありません。
ロックは、実際にはここで発生する主な問題ではありません。EF は、変更の保存呼び出しの間のみロックします (実際には、他のほとんどの ORM が使用する部分的にコミットされたトランザクションに対して追跡グラフを使用することの大きな利点の 1 つです)。
あなたを悲しませようとしているのは、追跡グラフそのものです。EF がどのように機能するか (ほとんどの場合) は、これまでに見たすべてのエンティティのコピーを保持し、それらをループして変更内容を見つけ、ナビゲーション プロパティをバックリンクで機能させるフィックスアップと呼ばれるプロセスを実行します。このプロセスは、コンテキストがこれまでに見たすべてのエンティティをループし、一連の操作 (追加、添付、削除、保存、クエリ、その他いくつか) で呼び出されます。これは、追跡グラフが大きい場合、このプロセスにかなりの時間がかかることを意味します。コンテキストを永久に維持すると、追跡グラフのサイズがデータベースのサイズに近づく傾向があり、扱いにくく遅くなります。
それは多くのことに依存しますが、ここにいくつかの考えがあります：例：
いずれにせよ、それは悪い考えだと思います。