Autofac - InstancePerHttpRequest vs InstancePerLif

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!

Answer 2

In Autofac per lifetime scope is a generic way to create custom scopes using nested lifetimes.

Using InstancePerLifetimeScope gives you per request scope, which adds component lifetime for single request and internally uses InstancePerLifetimeScrope for this component.

Use InstancePerLifetimeScope everywhere you need this, or if it is a problem to have a reference to Autofac.Integration.Mvc assembly in your service layer - create nested scopes manually on each beginning of request and use InstancePerLifetimeScope.

Answer 3

The only place in your application that's completely capable of making a decision about the lifetime of an object is at the composition root.

In this case you have a conflict -- you have a generic module that shouldn't have access to extension method provided by the MVC integration -- yet you need to have access to it in order for the lifetime to be managed properly. In this case, if your module can provide a reasonable default, like InstancePerLifetimeScope, then that's what I'd do at the module level. Then, you let the composition root override that behavior. In this case the composition root would change the lifetime to InstancePerHttpRequest. Since the last registration will override the earlier registrations, you should be in good shape.

I've actually moved away from creating modules that coexist with the assembly that contains a given layer for a couple of reasons:

1. It introduces a dependency on Autofac, which I don't want except at my composition root
2. It suggests that the module knows how it's lifetime should be managed, which isn't usually true. If it does, why not provide a factory or other classes which provide that lifetime management?

Instead (and in projects large enough to warrant), I create the modules at the composition root level as at this level I have explicit knowledge about how they should be wired together. Sometimes I'll create an Ioc assembly that contains the modules and that acts as a default composition root -- but this is often overridden at the "real" composition root (e.g., the console or MVC application that pulls in the Ioc assembly).