c# - Autofac - InstancePerHttpRequest vs InstancePerLifetimeScope

Question

What are the differences between the two scopes?

I am building Module(s) in each layer (Repository, Service, MVC App), but in order to have InstancePerHttpRequest you need the Autofac.Mvc assembly.

Which scope should I be using in my Repository and Service layer?

Answer 1

InstancePerHttpRequest and InstancePerApiRequest essentially do the same thing - you get a single instance of your service for each discrete web request. I'll use InstancePerHttpRequest for the rest of the answer, but keep in mind that these two are interchangeable.

InstancePerLifetimeScope means a new instance of the service will be created for every lifetime scope which asks for your service. Each web request gets its own fresh lifetime scope, so in practice, more often than not, these two will do the exact same thing.

The only real difference comes if you have a service registered under InstancePerHttpRequest and you request one of those services from another service which is registered as a SingleInstance. In this scenario:

• The SingleInstance component lives in the root scope
• The InstancePerHttpRequest component lives in a scope called "AutofacWebRequest", which is a child of the root scope

Autofac does not allow for resolution from child scopes - so essentially, the SingleInstance service cannot find the InstancePerHttpRequest service.

However, if in this scenario you had used InstancePerLifetimeScope (instead of InstancePerHttpRequest), then your services would resolve just fine.

I've written up a fairly exhaustive article with downloadable code that attempts to explain all this in detail - see here. Quoting from the article:

One common misconception here is that registering your component with InstancePerLifetimeScope in a WebAPI application means that your component lives in the scope of a web request – i.e. that “Lifetime” refers to “the Lifetime of the web request”. As you can see here, this is false.

The lifetime of your component is determined by the scope in which it was resolved.

Since the SingletonResolvable resolves its token from the root scope, that token instance lives in the root scope, not the scope of a web request. I’ve said it before, but I’ll say it again: this token will live until the entire application is disposed of (e.g. the IIS worker process is recycled). Anything which asks for a ScopeToken from the root scope will be given a reference to that token.

Hope that helps - I appreciate this question is now quite old, however its still very relevant!