1

I have an object that I would like to access the Windsor Container. I have done this by registering the container with the container itself. Like so:

public class WindsorContainerInstaller : IWindsorInstaller
{
  public void Install(IWindsorContainer container, IConfigurationStore store)
  {
    // no idea if this is a good idea or not
    container.Register(Component.For<IWindsorContainer>().Instance(container));
  }
}

public class Foo
{
  public Foo(IWindsorContainer container)
  {
    _container = container;
  }
  private IWindsorContainer _container;
}

I haven't seen any examples with anyone doing it this way. I tend to see examples with people accessing the container by a static class or a singleton class.

So my question is. Are there any issues registering the container with the container itself?

Update

The scenario is perhaps not as simple as my initial code suggests. If my object had a particular dependency I would specify that in the constructor, like this public Foo(IBar bar).

In this scenario Foo doesn't entirely know what dependency it needs.

public class Foo
{
  public Foo(IWindsorContainer container)
  {
    _container = container;
  }
  private IWindsorContainer _container;

  public void Add<T>(T entity)
  {
    var bar = _container.Resolve<IBar<T>>();
    bar.Create(entity);
  }
}
energ1ser
  • 2,703
  • 4
  • 24
  • 31
  • Yes - [Service Locator is an Anti-Pattern](http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/). Whether you reference the container statically or through the constructor, you are creating *coupling* with the DI container and making an application that is *more difficult to configure* by burying the required dependencies deep in the code instead of making them available through the constructor. – NightOwl888 May 24 '16 at 22:07
  • @NightOwl888 I think my situation may be a little more complicated then I made it out to be. I have updated my question to reflect this. – energ1ser May 24 '16 at 23:06
  • 1
    Check out https://github.com/castleproject/Windsor/blob/master/docs/typed-factory-facility.md Take care to Release everything you Resolve, even when using a factory. – Phil Degenhardt May 25 '16 at 04:06
  • 1
    It's not unheard of to [register the container itself](http://blog.ploeh.dk/2012/10/03/DependencyInjectioninASP.NETWebAPIwithCastleWindsor/), but its usually done for specific edge cases. You might want to open a new question explaining what Foo is supposed to do and why you feel registering the container is the solution (which, as @NightOwl888 pointed out, is an anti-pattern). Windsor is pretty flexible when it comes to resolving objects. It may already support what you need. – PatrickSteele May 25 '16 at 11:27
  • @PhilDegenhardt This seems to be exactly what I'm looking for. – energ1ser May 26 '16 at 03:57
  • I have seen this in Framework code, an example is NancyFx https://github.com/NancyFx/Nancy.Bootstrappers.Windsor/blob/master/src/Nancy.Bootstrappers.Windsor/WindsorNancyBootstrapper.cs#L85. Another example is in Factory classes. When people do this they must release the objects when done with them. – dbones Jun 02 '16 at 22:34
  • Does the FAQ explain it sufficiently? https://github.com/castleproject/Windsor/blob/master/docs/faq.md#why-wont-windsor-inject-itself-iwindsorcontainer-into-my-components – Krzysztof Kozmic Aug 20 '16 at 23:09

0 Answers0