16

I'm using Autofac to handle dependency injection in my application. However, I have one component that does some reflection magic at runtime and I don't know at compile-time what dependencies it will need.

Ordinarily, I would just have this component reference the Container directly and resolve whatever it wants. However, the class that is instantiating this class has no reference to the Container.

Effectively, my component has a dependency on Autofac. I'd prefer looser coupling, but that doesn't seem to be an option here. Is there a way to ask (in the constructor args, or using property injection, or whatever!) Autofac to give me a reference to the container in my constructor? Or, is there a cleaner way to have Autofac provide me with a magic service locator object that can resolve anything?

David Pfeffer
  • 38,869
  • 30
  • 127
  • 202
  • 2
    It would be interesting though to see what "magic" the component is doing. Perhaps there are other ways than the service locator pattern. Could you update with some code? – Peter Lillevold Aug 25 '11 at 13:28
  • I can describe it fairly well. As messages come in over a bus, the code determines what type the message is using some metadata, and then constructs said type. It then needs to find all implementors of `IConsume` (where `type` is the type from the metadata) using Autofac and then call the Consume method on it. – David Pfeffer Aug 26 '11 at 01:22
  • You mean like: http://kozmic.pl/2010/03/11/advanced-castle-windsor-ndash-generic-typed-factories-auto-release-and-more/ – Krzysztof Kozmic Aug 28 '11 at 22:02
  • Yes but little of that translates to Autofac. – David Pfeffer Aug 29 '11 at 10:51

3 Answers3

15

Yes, you can. Just take a dependency on the IComponentContext:

public class MyComponent
{
    IComponentContext _context;
    public MyComponent(IComponentContext context)
    {
        _context = context;
    }

    public void DoStuff()
    {
        var service = _context.Resolve(...);
    }
}

Update from the comments: the IComponentContext injected into MyComponent depends on the scope from which MyComponent was resolved. It is thus important to consider with what lifetime scope MyComponent is registered. E.g. using InstancePerLifetimeScope, the context will always resolve to the same scope in which the service depending on MyComponent lives.

Peter Lillevold
  • 33,668
  • 7
  • 97
  • 131
  • Will this work with multiple lifetime scopes? i.e. Will the IComponentContext be the base Container or the scope? – David Pfeffer Aug 25 '11 at 13:15
  • 3
    It will resolve `IComponentContext` from the scope in which `MyComponent` was resolved. So if `MyComponent` is registered as `InstancePerLifetimeScope`, `context` will always resolve from the expected scope. – Peter Lillevold Aug 25 '11 at 13:17
1

Supposing you have two components, A and B.

If A needs to know X about B before using it, this is Metadata interrogation and it is described in this excellent post.

Furthermore, even if you can't adapt your design to that post, you should again try to make sure if you really need to use your DI Container as a Service Locator.

At the time of this writting, the best blog post I could find describing it is this one.

Nikos Baxevanis
  • 10,868
  • 2
  • 46
  • 80
  • I'm not sure why you'd answer an already well-answered question with stuff that isn't related to my question at all... as I said, my issue is not knowing which "B" I will need to resolve until runtime. – David Pfeffer Aug 28 '11 at 14:28
  • 1
    @NikosBaxevanis +1, even if the OP didn't seem to get it. Both posts are excellent. This single phrase from Nicholas post resumes it all: "At the same time, there’s practically no excuse to use IContainer or IComponentContext in your components anymore". – rsenna Apr 07 '12 at 06:37
0

In other cases, when your component is not created by using DI, you still can use the service locator pattern. The Common Service Locator library on CodePlex is perfect for the purpose.

Daniel Leiszen
  • 1,827
  • 20
  • 39