Autofac IComponentContext vs ILifetimeScope

485 views
Skip to first unread message

ant...@radiusfintech.com

unread,
Jun 19, 2017, 11:02:46 AM6/19/17
to Autofac
I was passing the IContainer in a service so I read that it is not good to pass this around but instead use it only to the root of the app and pass either IComponentContext or ILifetimeScope . So I am trying to understand which shall I use IComponentContext or ILifetimeScope. Dont understand the difference. Can anyone explain when to use the first or the latter?

Thanks

Michael Powell

unread,
Jun 19, 2017, 1:10:03 PM6/19/17
to Autofac


On Monday, June 19, 2017 at 11:02:46 AM UTC-4, ant...@radiusfintech.com wrote:
I was passing the IContainer in a service so I read that it is not good to pass this around but instead use it only to the root of the app and pass either IComponentContext or ILifetimeScope . So I am trying to understand which shall I use IComponentContext or ILifetimeScope. Dont understand the difference. Can anyone explain when to use the first or the latter?

I don't know about IComponentContext, but I also learned that I should pass ILifetimeScope instead. This is automatically registered by Autofac and is preferred over your IContainer. Seems to work just fine.

Thanks

Alex Meyer-Gleaves

unread,
Jun 20, 2017, 1:10:16 AM6/20/17
to aut...@googlegroups.com

I think what is being referred to is the general guidance to avoid having services take a dependency on ILifetimeScope or any interface that represent the container. When you do this, you are exposing the container to the consumer in the form of the Service Locator anti-pattern.


It hides the dependencies that a service requires behind a single interface, making it difficult to know from outside the class what dependencies it has. You must go into the class implementation and track down calls to the Service Locator interface to find out what the dependencies are. In certain infrastructure components, such as those that are responsible for creating nested lifetime scopes, injecting the ILifetimeScope may be perfectly acceptable, but in general cases it is something that you should try to avoid.


Michael is correct that ILifetimeScope is always automatically registered and available for injection. It will always represent the current ILifetimeScope. The IComponentContext is also available in the same manner. The ILifetimeScope interface inherits from IComponentContext and adds additional members related to managing child lifetime scopes. IContainer inherits from ILifetimeScope and is simply a marker for the root lifetime scope. It does not add any additional members to ILifetimeScope.

Michael

unread,
Jun 20, 2017, 3:57:05 AM6/20/17
to aut...@googlegroups.com


On June 20, 2017 1:10:16 AM EDT, Alex Meyer-Gleaves <alex.mey...@gmail.com> wrote:
>
>
>The think what is being referred to is the general guidance to avoid
>having
>services take a dependency on ILifetimeScope or any interface that
>represent the container. When you do this, you are exposing the
>container
>to the consumer in the form of the Service Locator
><http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/>
>anti-pattern.

This is true. I've only run into one case wherein I needed to receive an ILS, and that was deep in the bowels of some customized and fairly advanced ASP.NET resolution classes.

Other than that, any access to your container of any sort is generally considered a form of the service locator anti-pattern.

>It hides the dependencies that a service requires behind a single
>interface, making it difficult to know from outside the class what
>dependencies it has. You must go into the class implementation and
>track
>down calls to the Service Locator interface to find out what the
>dependencies are. In certain infrastructure components, such as those
>that
>are responsible for creating nested lifetime scopes, injecting the
>ILifetimeScope may be perfectly acceptable, but in general cases it is
>something that you should try to avoid.
>
>
>Michael is correct that ILifetimeScope is always automatically
>registered
>and available for injection. It will always represent the current
>ILifetimeScope. The IComponentContext is also available in the same
>manner.
>The ILifetimeScope interface inherits from IComponentContext and adds
>additional members related to managing child lifetime scopes.
>IContainer
>inherits from ILifetimeScope and is simply a marker for the root
>lifetime
>scope. It does not add any additional members to ILifetimeScope.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Reply all
Reply to author
Forward
0 new messages