オートファック制御範囲と寿命

クズども · 2020年9月19日 12:51:52に投稿

Autofac制御範囲とライフサイクルについて学ぶのに良い記事があります。ライフサイクルスコープはアプリケーション内の作業単位に相当し、作業単位は最初にライフサイクルスコープを開始し、その後、その作業単位を必要とするサービスはライフサイクル範囲から解析されます。

ライフタイムスコープ

ライフトムスコープの作成

手動でスコープを作成し、処分してください。ライフタイムスコープは使い捨てで、部品の廃棄を追跡するので、必ず「Dispose()」を呼び出すか、「useing」文で包み込むようにしてください。

ログインが見えます。

ラベルライフタイムスコープ

ユニット内でサービスを共有する必要がある場合もありますが、シングルトンモードのようなグローバル共有機能は使いたくありません。例えば、ウェブアプリケーションのリクエストごとのライフサイクルの場合、InstancePerMatchingLifetimeScopeを使ってライフサイクルとサービスを特定できます。

例えば、メールを送信するコンポーネントがあり、トランザクションロジックは複数回メッセージを送信する必要があるため、メールサービスを各論理トランザクションスライスで共有できます。メールコンポーネントをグローバルシングルトンにしたくない場合は、以下のように設定できます。

ログインが見えます。

生涯スコープへの登録追加

Autofacはライフサイクルを作成する際に「オンフライ」で追加できます。これは、限定的な登録オーバーライドのような「スポット溶接」が必要な場合や、全体的に登録したくないスコープに追加の要素が必要な場合に役立ちます。これは、ContainerBuilderを受け取り登録を追加するBeginLifetimeScope()にラムダを渡すことで実現します。 (ライフサイクルを作成する際、グローバル登録なしで追加サービスを登録してください)

ログインが見えます。

インスタンススコープ

インスタンススコープは、インスタンスがリクエスト間でどのように共有されるかを決定します。サービスを要求する際、autofacは単一のインスタンススコープ、依存スコープごとに新しいインスタンス、またはスレッドやライフタイムスコープごとのHTTPリクエストなどのコンテキスト内のシングルトンを返すことができます。これは明示的なResolve()呼び出しから戻るインスタンスだけでなく、コンテナが内部で作成して他のコンポーネントの依存関係を満たすインスタンスにも適用されます。

依存関係ごとのインスタンス数
シングルインスタンス
ライフタイムスコープあたりのインスタンス数
マッチングのライフタイムスコープあたりのインスタンス
リクエストごとのインスタンス数
所有株あたりのインスタンス数
スレッドスコープ

依存関係ごとのインスタンス数

他のコンテナでは「トランジェント」や「ファクトリー」とも呼ばれ、サービスが要求されるたびに一意のインスタンスを返します。ライフサイクルが指定されていない場合、これがデフォルトの動作となります。

ログインが見えます。

各Resolve依存関係は新しいコンポーネントを返します。

ログインが見えます。

シングルインスタンス

同じインスタンスがすべてのリクエストとネストされたスコープで返されます。

ログインが見えます。

ライフタイムスコープあたりのインスタンス数

このスコープはネストされたスコープにも適用可能です。 1ライフタイムスコープコンポーネントは、ネストされたスコープ内に最大1つのインスタンスを持ちます。これは、単一の作業単位に特有のオブジェクトで、追加の論理単位をネストする必要がある場合に有用です。各ネストされたライフタイムスコープには、登録された依存関係の新しいインスタンスが割り当てられます。

ログインが見えます。

ライフタイムスコープのインスタンスコンポーネントを解析すると、入れ子スコープにはインスタンスが1つだけ(例:作業単位あたり)になります。

ログインが見えます。

マッチングのライフタイムスコープあたりのインスタンス

これはインスタンス・パー・ライフタイム・スコープに似ていますが、より正確なインスタンスと制御を共有することができます。ネストされたライフサイクルを作成する際には、ラベルを付けたり名前を付けたりできます。 per-matching-lifetime スコープを持つコンポーネントは、ネストされたライフタイムスコープに対して、特定の名前に一致するインスタンスが最大1つしか持てません。これにより、スコープ付きシングルトンの作成が可能となり、ネストされたサイクルがグローバルインスタンスを作成せずにコンポーネントを共有できます。

httpリクエストのような、ネストされたライフサイクルとして作成された単一作業単位に有用です。 HTTPリクエストごとにネストされたライフタイムが作成された場合、パーライフタイムスコープを持つコンポーネントはHTTPリクエストごとにインスタンスを持ちます。 (リクエストごとの生涯範囲については後述。)

ほとんどのアプリケーションでは、作業単位を表すために階層的なコンテナネスティングは1つだけで十分です。複数のネストレベルが必要な場合(例:global->request-transaction>)、タグを介して特定のレベルで共有するコンポーネントを作成できます。

ログインが見えます。

ネストされたライフサイクルが開始されると、タグはそのライフサイクルに関連付けられます。正しく名前のライフタイムスコープがない場合、マッチングするライフタイムスコープのコンポーネントを解決しようとすると例外が出ます。 (保存されていないタグのライフサイクルが解析されると例外が発生します。)

ログインが見えます。

リクエストごとのインスタンス数

一部のアプリケーションタイプは、MVCのように「リクエスト」タイプの意味論 ASP.NET 自然に持っています。これらのアプリケーションタイプの中で、「リクエストごとのシングルトン」という形を持つことが役立ちます。インスタンスごとのリクエストは、マッチングするライフタイムスコープのインスタンスごとを基に、よく知られたライフタイムスコープタグ、登録の利便性方法、共通アプリケーション向けの統合を提供しますタイプ(リクエストごとに1つのインスタンスは、マッチングライフタイムスコープの上に、よく知られたライフタイムタグ、登録利便性、共通アプリケーションタイプへの統合を提供することで構築されています)。基本的には、マッチングするライフタイムスコープ単位です。

つまり、現在リクエストが存在せず、インスタンスごとに登録されたコンポーネントを解析した場合、例外がスローされます。リクエストごとのライフタイムの扱い方を詳しく説明したFAQがあります。

ハイパーリンクのログインが見えます。

ログインが見えます。

所有株あたりのインスタンス数

所有されている暗黙の関係タイプで、新しいネストされたライフサイクルが作成されます。依存関係はインスタンスごとに所有されたインスタンスに登録することでホストインスタンスに限定できます。

ログインが見えます。

この例では、ServiceForHandlerサービスは所有されているMessageHandlerインスタンスのライフタイムにスコープが割り当てられます。

ログインが見えます。

スレッドスコープ

参照できます

ハイパーリンクのログインが見えます。

実際の戦闘

私はライフタイムあたりのインスタンススコープモードを使っています。

winformでは、呼び出しが実行されるたびにデータベースコンテキストを使用します。以下の図に示されています。

_dbContext.GetHashCode();
13583655
_dbContext.GetHashCode();
13583655
_dbContext.GetHashCode();
13583655

マルチスレッドや並行性の場合、同じデータベースコンテキストを使うと、データベースの追加、削除、変更、チェック時に例外が発生することがあります。

autofacにボタンを押すたびに新しいオブジェクトを返してほしいです。コードは以下の通りです:

ログインが見えます。

以下に示すように:

(終わり)

カーライル · 2022年9月8日 09:58:24に投稿

まさに私たちが必要としているものです

[出典] オートファック制御範囲と寿命

関連記事

閲覧したセクション