IoC.Resolve vs Constructor Injection

Question

I heard a lot of people saying that it is a bad practice to use IoC.Resolve(), but I never heard a good reason why (if it's all about testing than you can just mock the container, and you're done).

now the advantages of using Resolve instead of Constructor Injection is that you don't need to create classes that have 5 parameters in the constructor, and whenever you are going to create a instance of that class you're not gonna need to provide it with anything

Answer 1

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.

Answer 2

If you create classes that have 5 dependencies, you have problems other than IoC.Resolve.

Pulling dependencies (as opposed to having them pushed via constructor) completely misses the point of using IoC framework. You want to invert the dependencies. Not have your classes depend on IoC framework, but the other way around.

If you don't need all dependencies in certain scenarios, than perhaps you should split your class, or have some dependencies made optional by making them property dependencies.

---

Your classes depend on the container. They won't work unless you provide them with one. Whether it's a real one, or a fake one does not matter. They are inherently bound to the container via static dependency. This imposes additional work on you to do anything with your classes. Any time you want to use your class, you need to drag the container with them. For no benefit! Service locator is just one global bag of everything, which is against probably all tenets of object oriented programming.