I was wondering about a good practice around aggregating dependencies to reduce constructor parameters.
I have the need for many 'operation' objects that get injected. These operation objects are small, but may do work against several difference services (right now, about 8).
As of right now, I have a bsae class for these operations that take an aggregated service object. So, each operation needs to have a constructor that also takes this object and passes it to the base class constructor. The aggregate service object
is registered in Unity, so as long as the operation constructors only take this parameter (or other parameters that can automatically be resolved), this works fine.
The service object is instantiated with the singleton lifetime, and the service references are also injected. I should also mention that the container is configured via a configuration file.
I've done this primarily for ease of configuration: there will be dozens of these operations eventually. I was trying to avoid having to configure the constructor for each one to take the specific services that they need.
However, we're finding that some of these operations need to have additional constructor parameters.
Right now, I can configure the constructors for these operation objects to include the service object and the additional parameters via the <constructor> element. I was hoping to avoid this.
So, I guess my questions are:
- Is there any way to get Unity to resolve the service object automatically, while still specifying the other parameters via the config file? I'm guessing that this won't work.
- Is there a better approach to this? I toyed with the idea of having the service objects be a true singleton (having a static Instance property), or by having the object be a static member of the operations base class. These sound like hacks to
me; but I would prefer to not have to configure EACH operation's services.