ASP.NET MVC & Windsor.Castle: working with HttpContext-dependent services

问题

I have several dependency injection services which are dependent on stuff like HTTP context. Right now I'm configuring them as singletons the Windsor container in the Application_Start handler, which is obviously a problem for such services.

What is the best way to handle this? I'm considering making them transient and then releasing them after each HTTP request. But what is the best way/place to inject the HTTP context into them? Controller factory or somewhere else?

回答1:

With Castle Windsor you can use the PerWebRequest lifetime - that should fit pretty well with your requirements.

That means you can just inject the HTTP stuff into your services, and the container will take care of the proper lifetime management. However, this requires you to also register all these services (and all consumers of those services and so on) as PerWebRequest (or Transient) because if you register them as Singletons, they will hold on to stale (and possibly disposed) contexts.

回答2:

Just like Mark said, you need to register these http-dependent services either as PerWebRequest or Transient. Here's a sample that shows how to register and inject a HttpRequest or HttpContext:

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)));  
}

By using HttpRequestBase instead of HttpRequest you can easily mock it out for testing. Also, don't forget to register PerWebRequestLifestyleModule in your web.config.

回答3:

I just ran into this exact same problem, but my solution is somewhat different.

Interface:

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

Implementation:

/// <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); }
    }
}

I then register the IHttpContextProvider as a singleton in the container. I'm still a bit of a newbie when it comes to DI, so maybe I'm over complicating things, but from what I can understand, I can't have any singleton components depend on PerWebRequest lifestyle components, which makes sense (but that's what all examples do). In my solution, I depend on HttpContext.Current in an isolated component and I'm not interested in testing that. But every component that needs access to the HTTP context can get that by depending on IHttpContextProvider and easily mock that as needed.

Am I really over complicating things or are there any caveats in my solution?

来源：https://stackoverflow.com/questions/1818888/asp-net-mvc-windsor-castle-working-with-httpcontext-dependent-services