私のAutofac LifetimeScopeをMVCアプリケーションで使用することの欠点

Question

DI用にAutofacを使用してデスクトップ版用に書き留めた従来のコアライブラリを再利用するMVC UIラッパーを作成しています。私が直面している問題は、MVCがInstancePerRequestを必要としている間は、コアライブラリがライフタイムスコープで動作していて変更できないということです。

MVCで、サービスをInstancePerRequestスコープに登録すると、要求が完了する前にコアライブラリによって処理されます。それはMVCアプリケーションを不幸にします。
MVCアプリケーションのすべてのサービスにもLifeTimeScopeを使ってみました。ライフタイムスコープはRequest Lifeよりも短いので、MVCで動作するようです。

このアプローチには欠点がありますか？

メモ：レガシーコードでは、常にサービスはコンストラクタを介して注入されるのではなく、手動で解決されます。同様：

using (var scope = IocContainer.BeginLifetimeScope()) 
{ 
    var service = scope.Resolve<IMyService>(); 
    return service.FindAll(); 
} 

Answer 1

MVCは、サービスas noted in the documentation about sharing registrations across apps that have and apps that don't have request scopesためInstancePerLifetimeScopeで動作します。

あなた自身の生涯の範囲を作成するあなたのアプローチに潜在的に2つの問題があると思います。あなたがそれらと一緒に暮らすことができるかどうかは非常に多くのアプリに固有なので、あなた自身で判断する必要があります。

問題1：早期処分

あなたの例では、あなたには、いくつかの仕事をして、その仕事を返す、工場やサービスIMyServiceが解決されて表示されます。 usingステートメントの終わりには、所有ライフタイムスコープが廃棄されています。つまり、IMyServiceが処分され（IDisposableの場合）、IMyServiceが必要とする依存関係も処理されます。データベースのコンテキストや接続などの場合は、値を更新したり、削除された接続に対して追加のデータを読み取ることができないため、戻り値が無効になる可能性があります。

問題2：シングルトン/共有問題

寿命スコープは、しばしば作業単位またはコンテキストを共有必要なコンポーネントのセットを単離するために使用されます。たとえば、MVCでは、リクエスト全体に対してコントローラのインスタンスが1つしかありません。コントローラーオブジェクトを何回解決しても、そのリクエストでは同じインスタンスになります。データベース接続では、要求ライフタイム全体にわたって割り当てられたプールからの1つの接続も同様のことが分かります。

ライフタイムスコープを独自に作成することで、一種の論理作業単位を作成することもできます。 IMyServiceの依存関係はではなく、は残りのMVC要求と共有されます。実際には、小さな寿命のスコープのようなものですは、それ自身の要求またはそれ自身の作業単位です。重複はありません。

一般決議

doc I linked to earlierで述べたように、彼らはMVCと非MVCの文脈の両方で使用する必要があり、ちょうどMVC要求セマンティクスがスピンアップし、スコープの廃棄処理させる場合InstancePerLifetimeScopeようなものを登録可能なら。

これでうまくいかない場合は、ここで問題に取り組むことができるかどうか、または問題に対処する必要があるかどうかは、あなたとアプリケーションコードによって決まります。あなたがそれらに対処する必要がある場合は、それもアプリケーションに固有なので、提供する "ガイダンス"はありません - あなたはそれのためにあなた自身であります。