Управление областями времени жизни AutoFac для каждого сеанса и запроса в asp.net mvc 3

Я хочу использовать 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();
}

1. Как я могу указать AutoFac использовать мой requestScope в качестве отправной точки для получения зависимостей, чтобы реализации, которые я регистрирую как InstancePerLifetimeScope, разрешались с использованием моего requestScope?

2. Если это невозможно, могу ли я заставить AutoFac создать свою область действия -запроса из моей области сеанса?

3. Или я на неправильном пути здесь? Может ли быть другой способ сообщить AutoFac об этой иерархии?

Любая помощь или другие комментарии приветствуются.

В ответ Стивен.

Я все еще на ранней стадии создания прототипа, но возможные вещи, которые вы могли бы иметь в sessionScope:

• Пользовательские настройки
• Контекст аутентификации и авторизации (, например. идентификатор пользователя и роли)

Это не относится к приложению, которое я собираюсь создать, но в среде электронной коммерции -корзина может быть привязана к сеансу. Это, пожалуй, лучший конкретный пример. Это то, что вы ожидаете жить дольше, чем запрос, но короче, чем приложение.

Это может быть больше, но если у меня есть стратегия для UserPreferences, Authentication и Authorization, то эту стратегию можно применить и к другим компонентам, которые будут созданы позже.

Возможная альтернатива — получить всю необходимую информацию в начале запроса и поместить эти настроенные компоненты в область запроса.Это даст мне ожидаемый результат, но он не соответствует той модели, которую я имею в виду относительно приложения -> сеанса -> иерархии запросов. Я надеюсь создать систему, которая будет иметь смысл, поскольку я определенно не тот, кто будет ее поддерживать.