C# 在asp.net mvc 3中管理每个会话和请求的AutoFac生存期范围

我想在web应用程序中使用AutoFac。我有根容器，每个会话有一个子容器，每个请求有一个子容器。我试图找出管理这些生命周期范围的最佳方法。在Global.asax.cs中，我添加了以下内容：

protected void Application_Start(object sender, EventArgs e)
{
    var container = ...;
}

protected void Session_Start(object sender, EventArgs e)
{
    var sessionScope = container.BeginLifetimeScope("session");

    Session["Autofac_LifetimeScope"] = sessionScope;
}

protected void Application_BeginRequest(object sender, EventArgs e)
{
    var sessionScope = (ILifetimeScope) Session["Autofac_LifetimeScope"];
    var requestScope = sessionScope.BeginLifetimeScope("httpRequest");

    HttpContext.Current.Items["Autofac_LifetimeScope"] = requestScope;
}

protected void Application_EndRequest(object sender, EventArgs e)
{
    var requestScope = (ILifetimeScope)HttpContext.Current.Items["Autofac_LifetimeScope"];
    requestScope.Dispose();
}

protected void Session_End(object sender, EventArgs e)
{
    var sessionScope = (ILifetimeScope)Session["Autofac_LifetimeScope"];

    sessionScope.Dispose();
}

protected void Application_End(object sender, EventArgs e)
{
    container.Dispose();
}

如何告诉AutoFac使用我的requestScope作为获取依赖项的起点，以便我注册为InstancePerLifetimeScope的实现将使用我的requestScope解决

如果这是不可能的，我可以让AutoFac在会话范围外创建其每请求生存期范围吗

还是我走错了方向？有没有其他方法可以让AutoFac了解这种层次结构

任何帮助或其他意见都将不胜感激

---

作为对史蒂文的回应

我仍处于原型设计的早期阶段，但在sessionScope中可能会有一些东西：

• 用户偏好
• 身份验证和授权上下文（例如用户身份和角色）

与我将要构建的应用程序无关，但在电子商务环境中，购物车可以是会话范围的。这可能是最好的具体例子。它比请求的寿命长，但比应用程序的寿命短

可能不止这些，但是如果我有一个UserPreferences、Authentication和Authorization的策略，那么这个策略也可以应用到以后创建的其他组件上

---

一种可能的替代方法是在请求开始时获取所有必要的信息，并将这些配置的组件放在请求范围内。它将给我预期的结果，但它与我心目中关于应用程序->会话->请求层次结构的模型不匹配。我希望创建一个有意义的系统，因为我肯定不是维护它的人。

您需要做的是实现自己的

Autofac.Integration.Mvc.ILifetimeScopeProvider

。此接口控制如何/在何处生成请求生存期范围。默认的一个，

Autofac.Integration.Mvc.RequestLifetimeScopeProvider

，根据每个请求处理生存期范围的创建、处理和维护

，我强烈建议，如果你打算这样做。这是我能想到的包含工作代码的最好的示例，显示了其中一项的责任

ILifetimeScopeProvider

的实现将是获取会话子容器，从中生成请求容器，并在请求结束时清理请求容器。如果会话容器不存在，您可能还希望在其中创建会话容器。处理会话容器的清理/处置在这里可能很棘手，但从设计的角度来看，如果它都在一个地方，而不是提供者中的一些地方，或者应用程序类中的一些地方，那就更好了

一旦您拥有了

ILifetimeScopeProvider

，您将在设置依赖项解析程序时使用它

var scopeProvider = new MyCustomLifetimeScopeProvider(container, configAction);
var resolver = new AutofacDependencyResolver(container, scopeProvider);
DependencyResolver.SetResolver(resolver);

关于会话级别范围的概念，有几句警告：

您的内存占用可能非常大。您将为系统中的每个用户提供一个终生范围。虽然请求生存期会弹出并很快消失，但这些会话级别的作用域可能会存在很长时间。如果您有很多会话范围的项，那么每个用户都会有相当大的内存使用量。如果人们在没有正确注销的情况下“放弃”他们的会话，那么这些东西就会活得更长

生存期范围及其内容不可序列化，它没有标记为

[Serializable]

。。。即使是这样，生活在其中的解析对象也不一定都标记为可序列化。这一点很重要，因为这意味着您的会话级生存期作用域可能在具有内存会话的单个框上工作，但如果您使用SQL会话或会话服务部署到服务器场，则会出现问题，因为会话无法序列化存储的作用域。如果您选择不序列化作用域，那么跨机器的每个用户都有不同的作用域，这也是一个潜在的问题

会话并不总是重新水化。如果被访问的处理程序（例如web表单）没有实现，则会话不会被重新水化（无论它是否在proc中）。默认情况下，Web表单和应用程序实现了这一点，因此您不会看到任何问题，但是如果您有需要注入的自定义处理程序，您将遇到一些障碍，因为这些请求不存在“会话”

会话\u结束并不总是触发，如果使用进程外会话状态，则实际上无法获取会话结束事件，因此无法清理

---

考虑到这些限制，通常最好远离会话存储的作用域。然而。。。如果这就是你要做的，那么ILifetimeScopeProvider就是一种方法。

Nicholas Blumhardt在CodeProject上发表了一篇文章。但那篇文章只是给出了一些不好的建议？我可以想象，有一些组件将具有与会话相同的生命周期，因此这看起来是一个很好的方法。应用程序不会有很多用户，也不需要将其部署在服务器场上。但是您提出了一些有效的观点。2b，当扩展到web场时，您的应用程序中会出现内存泄漏，因为当使用进程外会话状态时，

Session\u End

将永远不会被调用。在那篇文章中，我不认为Nick是在“给出建议”甚至使用session提供了一个更具体的例子来解释嵌套层次结构是如何工作的。这一点很好，@Steven-我在问题列表中添加了这一点，并在一条注释中指出，如果不实现IRequiresessionState，那么就不会有