Autofac - InstancePerHttpRequest vs InstancePerLifetimeScope
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?
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!
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:
- It introduces a dependency on Autofac, which I don't want except at my composition root
- 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).
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
.