I have a class for products import from CSV file operation which requires about 7 parameters. This is an info which is definitely needed for importer.
All of this pa
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.
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.