It's not necessarily a bad thing to mix Constructor Injection and Property Injection, but it may not be that common. As an overall strategy, avoid Property Injection since it's much more difficult to implement correctly (this may sound counter-intuitive, but it's true).
It's important to understand when to use each pattern.
- Constructor Injection should be your default injection pattern. It's super-easy to implement and can guarantee invariants: assign it to a read-only field to ensure the consumer's invariants.
- Property Injection can be used when you have a good Local Default implementation, but you want to follow the Open/Closed Principle and allow advanced users to extend the class by providing an alternative implementation.
You should never apply Property Injection because of constructor cosmetics.
When you require too many dependencies, it's a sign that you may be violating the Single Responsibility Principle - the class is simply trying to do too much at once.
Instead of introducing a Parameter Object (otherwise a good suggestion), a better option is to encapsulate two or more of the dependencies into an aggregating service that orchestrates the interaction of these dependencies.
Imagine that your initial constructor looks like this:
public MyClass(IDep1 dep1, IDep2 dep2, IDep3 dep3, IDep4, dep4, IDep5 dep5)
After applying a bit of analysis, you figure out that in this case IDep1, IDep3 and IDep4 will be used together in a particular way. This will allow you to introduce an aggregation service that encapsulated these like this:
public class AggService : IAggService
{
public AggService(IDep1 dep1, IDep3 dep3, IDep4 dep4)
{
// ...
}
// ...
}
You can now rewrite the original constructor to this:
public MyClass(IAggService aggSrvc, IDep2 dep2, IDep5 dep5)
and so forth...
It is very common that the aggregate service turns out to be a proper concept in it's own right, and suddenly you have a richer API than when you started.