2

In the case where your factory takes the IOC container as a constructor parameter and then uses the container to resolve an interface.

It is often stated that the only place the container should be referenced is your application entry point (Composition Root). Having the container in the factory goes against this

Is this an anti-pattern? Is it bad? Are there alternatives?

4
  • What arguments are there for claiming it's an anti-pattern ? Commented Oct 22, 2014 at 0:28
  • @alfasin It is often stated that the only place the container should be referenced is your application entry point. Having the container in the factory goes against this. Commented Oct 22, 2014 at 0:33
  • I see, it confused me because in (Java) Spring it's called the application-context. It is considered as bad practice in Spring because you should allow the container to create your objects automagically (via annotations/xml-config file) - not create them yourself. That said - I'm not familiar with C# frameworks and if the same thing applies to them as well. Commented Oct 22, 2014 at 1:04
  • 2
    It depends on where you put that Factory class: blog.ploeh.dk/2012/03/15/ImplementinganAbstractFactory Commented Oct 22, 2014 at 3:12

1 Answer 1

1

There's few you can do if you need to build objects inside your application and those objects need dependency resolution. You will find many blogposts about using this as only viable solution for certain problems, however you can still solve it in 2 elengat ways (at least) withohut exposing directly the Container outside the composition root (wich is Evil, Avoidable and BadPractise).

1) You create the factory as a Lambda method in CompositionRoot, most frameworks allows to do that (If you needed complex initialization and your Framework not allow that initialization but allow to register "custom injector", you'll probably need that in very few places of your code).

2) You wrap the "build" (or equivalent name) method of your container inside a FactoryClass, and then you inject that FactoryClass into a more specific Factory that does extra initialization steps (if you need to do so), else you inject FactoryClass directly (most frameworks may inject this kind of factories for you).

In Both cases there's no explicit reference to the Container outside CompositionRoot and that prevent the "Service Locator" pattern (wich cause enexpected dependencies by allowing users to access everything causing hard to debug side effects, especially when you deal with programmers that don't understand Dependency Injection and maintenability problems).

Of course, one of the main purposes of IoC Containers is to remove calls to "new" in user code wich allows to decouple creation and use, so most people just call "new" inside factories and prevent some code bloat (it's about the "Single Responsibility" principle, the responsability of a Factory is to "create", so for most people the simpler and hence the most maintenable solution is to use "new" directly).

Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.