ASP.NET MVC & Windsor.Castle: Arbeiten mit HttpContext-abhängigen Diensten

Question

Ich habe mehrere Dependency-Injection-Dienste, die von Sachen wie HTTP-Kontext abhängig sind. Im Moment konfiguriere ich sie als Singletons der Windsor-Container in der Application_Start-Handler, die offensichtlich ein Problem für solche Dienste ist.

Was ist der beste Weg, damit umzugehen? Ich überlege mir, sie transient und dann nach jeder HTTP-Anfrage freizugeben. Aber was ist der beste Weg, um den HTTP-Kontext in sie zu injizieren? Controller Fabrik oder woanders?

Answer 1

Mit Castle Windsor können Sie die PerWebRequest Lebensdauer verwenden - das sollte ziemlich gut zu Ihren Anforderungen passen.

Das bedeutet, dass Sie einfach das HTTP-Zeug in Ihre Dienste injizieren können, und der Container wird sich um das richtige Lifetime Management kümmern. Dies erfordert jedoch, dass Sie auch alle diese Dienste (und alle Konsumenten dieser Dienste usw.) als PerWebRequest (oder Transient) registrieren, da sie, wenn Sie sie als Singletons registrieren, an veralteten (und möglicherweise entsorgten) Kontexten festhalten.

Answer 2

Genau wie Mark sagte, müssen Sie diese http-abhängigen Dienste entweder als PerWebRequest oder Transient registrieren. Hier ist ein Beispiel, das zeigt, wie sich registrieren und ein Httprequest oder Httpcontext zu injizieren:

public class Service { 
    private readonly HttpRequestBase request; 

    public Service(HttpRequestBase request) { 
     this.request = request; 
    } 

    public string RawUrl { 
     get { 
      return request.RawUrl; 
     } 
    } 
} 

... 

protected void Application_Start(object sender, EventArgs e) { 
    IWindsorContainer container = new WindsorContainer(); 
    container.AddFacility<FactorySupportFacility>(); 
    container.AddComponentLifeStyle<Service>(LifestyleType.Transient); 

    container.Register(Component.For<HttpRequestBase>() 
     .LifeStyle.PerWebRequest 
     .UsingFactoryMethod(() => new HttpRequestWrapper(HttpContext.Current.Request))); 

    container.Register(Component.For<HttpContextBase>() 
     .LifeStyle.PerWebRequest 
     .UsingFactoryMethod(() => new HttpContextWrapper(HttpContext.Current))); 
} 

Durch die Verwendung von HttpRequestBase statt HttpRequest Sie leicht zum Testen aus verspotten kann. Vergessen Sie auch nicht, PerWebRequestLifestyleModule in Ihrer web.config zu registrieren.

Answer 3

Ich lief gerade in genau das gleiche Problem, aber meine Lösung ist etwas anders.

Schnittstelle:

public interface IHttpContextProvider 
{ 
    /// <summary> 
    /// Gets the current HTTP context. 
    /// </summary> 
    /// <value>The current HTTP context.</value> 
    HttpContextBase Current { get; } 
} 

Umsetzung:

/// <summary> 
/// A default HTTP context provider, returning a <see cref="HttpContextWrapper"/> from <see cref="HttpContext.Current"/>. 
/// </summary> 
public class DefaultHttpContextProvider : IHttpContextProvider 
{ 
    public HttpContextBase Current 
    { 
     get { return new HttpContextWrapper(HttpContext.Current); } 
    } 
} 

melde ich mich dann auf die IHttpContextProvider als Singleton in den Behälter. Ich bin immer noch ein Anfänger, wenn es um DI geht, also bin ich vielleicht etwas komplizierter, aber von dem, was ich verstehe, kann ich keine Singleton-Komponenten von PerWebRequest Lifestyle-Komponenten abhängig machen, was sinnvoll ist (aber das ist, was alle Beispiele tun). In meiner Lösung bin ich auf HttpContext.Current in einer isolierten Komponente angewiesen und ich bin nicht daran interessiert, das zu testen. Aber jede Komponente, die Zugriff auf den HTTP-Kontext benötigt, kann dies erreichen, indem sie von IHttpContextProvider abhängig ist und dies bei Bedarf leicht nachahmen kann.

Bin ich wirklich über komplizierter Dinge oder gibt es irgendwelche Vorbehalte in meiner Lösung?