The basic idea behind setter-based DI is that once the object is created (mainly with no argument constructors), a setter can be called to supply the dependencies to form an object graph, or just to supply the mock object for testing purposes.

Constructor-based DI is appropriate if there are only a couple of constructor parameters. If there are lots of constructor parameters, it will look messy. Even multiple versions of a constructor will not help much. In this case, you should rely on setter-based DI.

Ideally, all optional or conditional dependencies should be supplied through setter-based DI. The drawback to this approach is that you should make sure the setter methods are called before a client object starts using it. Another risk in using the setter method is that the dependency being altered at a later part of execution will result in an unexpected or ambiguous result, which is sometimes hard to trace. Also, if configuration is not done properly with the setter approach, you may end up with a circular dependency, which you could face at runtime.