EF DbContextはコンテキストが一意であることを保証します

クズども · 掲載地 2020/08/22 10:21:31

EFを使ってデータベースを操作し、同じHTTPリクエスト内でDbContext(データベース操作コンテキストクラス)を抽出して一意性を確保し、記事ではEntity Frameworkコンテキストの一意性を確保するために2つの方式を用い、.NET Coreプラットフォーム上の解決策を添付しています。

選択肢1

オブジェクトがグローバルに一意であることが保証されているなら、典型的なデザインパターンを思い浮かべるでしょう:シングルトンモード、つまり使うオブジェクトがスレッド内で一意でなければならない場合?

データスロット:CallContext、msdnのcallcontentの説明を参照してください。

CallContextは、メソッド呼び出し用のスレッドローカルストアに似た専用のコレクションオブジェクトであり、各論理実行スレッドに固有のデータスロットを提供します。データスロットは他の論理スレッドのコールコンテキスト間で共有されません。 CallContextは、実行コードのパスに沿って往復し、そのパス内の個々のオブジェクトによって検査される際にCallContextに追加されます。

つまり、現在のスレッドはオブジェクトをスレッドのローカルストレージに保存し、スレッドが破壊されるのと同様にオブジェクトも破壊されます。

コードの使用:

ログインが見えます。

使用シナリオ:個人的には、オブジェクトをスレッド内でグローバルに使いたい場合に使われ、他のスレッドパッケージ拡張スレッドがアクセスできない場合に使われると思います。例えば、EFのデータコンテキストでは、各リクエストごとにスレッドが生成され、この時点で異なる関数が使用できるようにデータコンテキストオブジェクトが作成され、最終的にトランザクション問題を避けるために共同コミットされます。もちろん、変数を作成して使えるか尋ねる人もいるかもしれませんが、それも同じ目的を達成できますが、このオブジェクトは他のスレッドデータとも相互作用することがあり、スレッド内で一意であるという概念に反します。

選択肢2

このシナリオはウェブのhttpリクエストに基づいており、すべてのリクエストが新しいスレッドとなり、コードは以下の通りです。

ログインが見えます。

.NET Coreでの「CallContext」の使用

CallContextはもはや利用できていないことが分かっています。 NETStandard または .NET Core です。

しかし、Asynclocalを使って<T>CallContextを模倣することもできます。以下の静的クラスを作成するだけです:

ログインが見えます。

参照が必要な名前空間:

ログインが見えます。

また使いやすいです(ここではCommonライブラリにCallContextを入れています):

ログインが見えます。

キュウリ · 掲載地 2020/08/25 23:38:22

香りがする香りがしますよね?

クズども · 掲載地 2020/08/26 21:37:39

Cucumber 2020-8-25 23:38に投稿
香りがする香りがしますよね?

asp.net コアのデフォルトの注入ライフサイクルが私のニーズを満たしていません

シングルトン:IServiceProviderオブジェクトによって作成されたサービスインスタンスは、IServiceProviderオブジェクトにルートコンテナとして保存されるため、同じ種類のサービスインスタンスに対して同じルートを持つ複数のIServiceProviderオブジェクトはすべて同じオブジェクト上に存在します。
Scoped:IServiceProviderオブジェクトによって作成されたサービスインスタンスはそれぞれ保存されるため、同じIServiceProviderオブジェクトが提供する同じタイプのサービスインスタンスはすべて同じオブジェクトとなります。
一時的:各サービス提供リクエストごとに、IServiceProviderオブジェクトは常に新しいサービスインスタンスを作成します。

[出典] EF DbContextはコンテキストが一意であることを保証します

関連記事

閲覧したセクション