1

過去に Castle Windsor を使用していた Web アプリケーションでの Autofac の使用を調査しています。

私が Autofac で本当に気に入っているのは、Windsor で DependancyResolvers などを作成するのとは対照的に、ラムダ式を介して動的コンポーネント構築を表現できることです。

私が持っている 1 つのシナリオは、特定のコンポーネントを ASP.NET セッション レベル スコープで登録することです。Windsor では、新しい LifestyleManager を作成/ソースしますが、Autofac では次のように思いつきました。

//Register SessionContext at HTTP Session Level
builder.Register(c =>
{
    HttpContext current = HttpContext.Current;

    //HttpContext handes delivering the correct session
    Pelagon.Violet.Core.Interfaces.SessionContext instance = current.Session["SessionContext"] as Pelagon.Violet.Core.Interfaces.SessionContext;

    if (instance == null)
    {
        instance = c.Resolve<Pelagon.Violet.Core.Interfaces.SessionContext>();
        current.Session["SessionContext"] = instance;
    }

    return instance;
})
.FactoryScoped();

ある時点で、これを拡張メソッドに変えることができるかもしれません。HttpContext.Current.Session が null の場合、Web アプリでのみ使用する必要があるため、この実装が爆撃することを受け入れます。

質問は：

Autofac でのこのような登録のベスト プラクティスは何ですか。ネストされたコンテナーなどの使用について多くの言及を見てきましたが、具体的な例はありません。上記のアプローチの何が問題なのかを理解したいと思っています (私が考えることができるのは、自動破棄のものだけです)。

ありがとう。

4

1 に答える 1

0

これは問題ないようです。

コンポーネントを「ExternallyOwned()」とマークすると、Autofac がそれを呼び出さないようDispose()になります。

ここでの唯一の落とし穴は、セッション スコープのコンポーネントが現在のコンテナーを介して独自の依存関係を解決できるため、現在の要求に属する可能性のあるものへの参照を保持できることです (たとえば)。ただし、これはテストで簡単に見つけることができます。

于 2009-09-10T05:00:49.217 に答える