In object oriented programming, it’s important to clearly define the relations between objects. When you’re looking at a given object dependencies, it should be intuitive to understand how the object behaves and what are the other objects it relies on by looking at its public API.

Another reason would be that your object can’t live without the dependency resolver. If you want to reuse your object elsewhere -in an application that uses another dependency resolver component- you’ll then have to rethink the way your object get its dependencies and refactor it.

When a service has many dependencies, injecting a dependency resolver to let the service manage its dependency by its own might be tempting and relevant. But this solution -which introduces the listed above drawbacks- does not address the real problem, which is introduced by your design.

You should first ask yourself the question; Why your object relies on all these dependencies.

In object-oriented programming, the single responsibility principle states that every context (class, function, variable, etc.) should define a single responsibility, and that responsibility should be entirely encapsulated by the context. All its services should be narrowly aligned with that responsibility. Source: Wikipedia

This definition clearly prevents designs that provides a highly coupled – non orthogonal – objects. If you want for example to design a user manager that fetch users from your database and manage their roles, your design should consider providing a service per responsibility: A service that fetch users and save them to your database and another service that manages the users roles.