I'm using dependency injection for all of my service classes. The majority of the services that I'm injecting dependencies into have several common dependencies that they all use, such as ILogService
, IMessageService
(for displaying messages to the user), IFileSystemService
(abstracting the File class so that I can unit test things that rely on reading files), IDateTimeService
(abstracting DateTime so that I can inject dates during unit testing), IConfigurationService
(so that I can inject application configuration settings during unit testing), and so on. The result is that my service classes all end up with a bunch of constructor arguments, since most of them have a minimum of four or five common dependencies, plus whatever their specific dependencies are (IOrderService
, ICustomerService
, etc.)
I've been considering throwing all of my commonly needed dependencies into a facade like IEnvironmentService
to cut down on the dependencies, but that seems like it would violate the single responsibility principle since that new service would have methods to handle logging, messaging, reading/writing files, and so on (plus just the fact that it would have so many methods seems bad).
What's the recommended way of handling this situation? I'm trying to prevent my constructors from having a ton of parameters, but also not violate single-responsibility.