IoC.Resolve vs Constructor Injection

IoC.Resolve<> is an example of the Service Locator pattern. That pattern imposes a few restrictions that constructor injection does not:

  • Objects can have no more fine-grained context than the application domain, due to the static calls
  • Objects decide which versions of dependencies to resolve. All instances of a certain class will get the same dependency configuration.
  • The temptation to couple code to the container is high, for example instead of creating an intention-revealing factory.
  • Unit testing requires container configuration, where the classes could just be created and used otherwise. (This is especially troublesome when you want to test multiple configurations of the same class, due to the second issue above.)
  • An application’s structure cannot be inferred from its public API. (Constructor parameters are a good thing. They are not a problem you should feel the need to solve.)

These limitations, in my mind, relegate the Service Locator pattern to a middle ground between big-ball-of-mud and dependency injection: useful if you must use it, but by far not the best choice.

Leave a Comment