Abhängigkeitsinjektion Container pro Anforderung

Question

Es ist sehr üblich, Dependency Injection-Container für die ASP.NET-Anwendung zu erstellen, so dass sie während der Lebensdauer der Anwendung bestehen.

Ich erstelle den DI-Container in jeder Anfrage und lasse ihn am Ende der Anfrage frei.
Der Hauptzweck ist, dass jeder DI-Container das Disposing von Objekten unterstützt, wenn der Container entsorgt wird.

---

Zusätzlich: Wenn ich brauche Ressourcen unter den Anforderungen (NHibernate Session) zu teilen Ich halte sie nur in einer statischen Variablen und kapseln diesen Wert in einem Objekt pro Anfrage. Gefällt mir:

public class SessionFactoryAggregator : ISessionFactory { 
    static ISessionFactory actualFactory; 

    // Implement ISessionFactory and proxy calls to the actualFactory 
} 

Dies ist nur simulierte Singleton-Muster.

---

Meine Fragen:

1. Ist es in Ordnung, das zu tun?
2. Wenn nicht warum und was sollte stattdessen getan werden?
3. Alle bekannten Leistungsprobleme in diesem Ansatz?

---

Update: Im Moment ist Schloss Windsor durch meine eigene Abstraktion von DI-Provider verwenden, so ist der eigentliche Behälter steckbar.

Danke.

Answer 1

Wenn es für Sie arbeitet, dann ist es OK :)

Wegen der staatenlos Art von Web-Anwendungen, dies zu tun sollte Ihnen keine funktionellen Probleme, weil Sie einfach gehen, einen Container pro Anfrage haben und die verschiedenen Instanzen werden einfach unabhängig voneinander leben.

Aus Skalierbarkeit Sicht jedoch diese kann nicht der effizienteste Ansatz sein (aber denken Sie daran, dass Sie die Leistung statt erraten messen sollte), wie die Anwendung wird die Verdrahtung und eine Menge von Ressourcen nach unten reißen das könnte genauso gut geteilt worden.

Die meisten DI-Container sind in der Lage, die Objektlebensdauer zu verwalten, und die meisten davon sind sogar webfähig, was bedeutet, dass Sie in der Lage sein sollten, bestimmten Komponenten eine "per-request" -Lebensdauer zu geben nach jeder Anfrage entsorgt werden.

Das würde Ihnen erlauben, andere Komponenten als Singletons (das Lebenszeitmuster, nicht das schöpferische Muster) am Leben zu erhalten, so dass sie unter mehreren Anfragen geteilt werden können. Dies kann oft eine gute Idee für Datenzugriffskomponenten sein, die normalerweise threadsicher sind, da sie keinen veränderbaren Zustand besitzen.