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.
Ioc.Resolve is essentially the Service Locator pattern. It has its place, but is not ideal. Constructor injection is preferred from an architecture standpoint, as dependencies are more explicit, whereas the SL hides the dependencies within a class. This reduces testability, and makes the process more complex than it needs to be.
If I may, I would suggest you read my series on techniques to reduce code coupling, which covers SL, DI, and IoC.
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.