依存性注入要求ごとのコンテナ

Question

ASP.NETアプリケーションの依存性注入コンテナを作成して、アプリケーションの存続期間中に存続させることは非常に一般的です。

それぞれのリクエストでDIコンテナを作成し、リクエストの最後にDIコンテナを解放します。
主な目的は、任意のDIコンテナが、コンテナが廃棄されるときにオブジェクトを廃棄することをサポートすることです。

---

追加：私は要求（NHibernateのSessionFactoryの）間でリソースを共有する必要がある場合私は静的変数でそれらを維持し、要求ごとのオブジェクトにその値をカプセル化します。このように：

public class SessionFactoryAggregator : ISessionFactory { 
    static ISessionFactory actualFactory; 

    // Implement ISessionFactory and proxy calls to the actualFactory 
} 

これはちょうどシミュレートされたシングルトンパターンです。

---

私の質問：

1. は、それはそれを行うにはOKですか？
2. なぜではなく、代わりに何をすべきか？
3. この手法のパフォーマンスに関する既知の問題はありますか？

---

アップデート：私はDIプロバイダの私自身の抽象化を通じて城ウィンザーを使用瞬間ので、実際のコンテナがプラグ可能です。

ありがとうございました。

Answer 1

それはあなたのために働く場合、それはOKです:)

ため、Webアプリケーションのステートレスな性質のため、これを実行すると、あなたに任意の機能の問題を与えるべきではありません、あなたは、単にリクエストごとにコンテナを持ってしようとしているので、複数のインスタンスは単に相互に独立しています。

しかし、このはであることが最も効率的な方法ではありません（しかし、推測の代わりにパフォーマンスを測定することを忘れないでください）。アプリケーションが配線され、多くのリソースを引き裂く可能性があります。ちょうどよく分かち合いました。

ほとんどのDIコンテナにはオブジェクトのライフタイムを管理する機能があり、ほとんどはWeb対応であるため、特定のコンポーネントには「リクエストごと」の有効期間があることを伝える必要があります。各要求の後に処分する。

これは、他のコンポーネントを複数のリクエスト間で共有できるように、シングルトン（生存パターンであり、クリエーションパターンではない）として生きているようにします。これは、変更可能な状態を保持しないため、通常はスレッドセーフであるデータアクセスコンポーネントにとっては、しばしば良い考えです。