静的クラスライブラリにdbコンテキストを置くことの長所と短所

Question

私たちには、繰り返し実行されるマルチコンテキストタスクを扱う静的クラスライブラリがあります。静的クラスのメンバーとしてEF dbコンテキストを作成するのは悪い習慣ですか？

DBコンテキストは、理由により処分されることを意味します。それらを頻繁に配置することで、接続プールが「流れている」状態になり、おそらく（ここでは私が推測している）テーブルがロックされたままでないことが保証されます。

静的クラスでDBコンテキストを使用する際に問題が発生する場合がありますか、これをやめようとしていますか？

Answer 1

IMOこれは間違いなくあなたがやりたいことではありません。

実際にロックすることは、実際にあなたが持っている主な問題ではありません。 EFは、セーブチェンジコール（実際には、他のほとんどのORMが使用する部分的にコミットされたトランザクションにトラッキンググラフを使用する大きなメリットの1つ）の間だけロックします。

greifを引き起こす原因は、追跡グラフそのものです。 EFが（ほとんどの場合）どのように動作するかは、それまでに見られたすべてのエンティティのコピーを保持し、変更されたものを見つけ出すためにループし、フィックスアップと呼ばれるプロセスを実行し、ナビゲーションプロパティをバックリンクで使用できるようにすることです。このプロセスは、コンテキストが今までに見たことのあるすべてのエンティティをループし、一連の操作（追加、添付、削除、保存、クエリなど）で呼び出されます。つまり、トラッキンググラフが大きい場合、このプロセスにはかなりの時間がかかります。あなたの文脈を永遠に生かし続ければ、追跡グラフのサイズはデータベースのサイズに近づき、扱いにくく、遅くなります。

Answer 2

それは多くのものに依存しますが、ここではいくつかの考えは、例えば、次のとおりです。

• あなたはサービス層の上にEFを使用している場合 - 私はEFのコンテキストを使用していることを考えていないとして、その後、並行性が問題になる可能性がありますスレッドセーフです。つまり、問題なく同時にすべてのスレッドから使​​用することができます。
• エンティティをコンテキストで追跡していれば（そして、そうでないと思っても）、コンテキストはかなり時間がかかるでしょうすべてのデータベースエンティティを含む可能性があります。次に、パフォーマンスの問題が発生します。

いずれにせよ、私はそれは悪い考えだと思います。