How Can I Redesign My C# Application To Avoid Constructor Injection Overload?

Question

I am still new to DI and Unit Tests. I have been tasked with adding Unit Tests to some of our legacy code. I am working on a WCF web service. A lot of refactoring has had to be done. Monster classes split into separate classes that make sense. Monster methods split to multiple methods. And lastly, creating interface classes for external dependencies. This was done initially to facilitate mocking those dependencies for unit tests.

As I have gone about this the list of dependencies keeps growing and growing. I have other web services to call, SQL Servers and DB2 Databases to interact with, a config file to read, a log to write to, and reading from Sharepoint data. So far I have 10 dependencies. And every time I add one it breaks all my Unit Tests since there is a new parameter in the constructor.

If it helps, I am using .Net 4.5, Castle Windsor as my IOC, MSTest, and Moq for testing.

I have looked here How to avoid Dependency Injection constructor madness? but this doesn't provide any real solution. Only to say "your class may be doing too much." I looked into Facade and Aggregate services but that seemed to just move where things were.

So I need some help on how to make this class to "less" but still provide the same output.

public AccountServices(ISomeWebServiceProvider someWebServiceProvider,
        ISomeOtherWebProvider someOtherWebProvider,
        IConfigurationSettings configurationSettings,
        IDB2Connect dB2Connect,
        IDB2SomeOtherData dB2SomeOtherData,
        IDB2DatabaseData dB2DatabaseData,
        ISharepointServiceProvider sharepointServiceProvider,
        ILoggingProvider loggingProvider,
        IAnotherProvider AnotherProvider,
        ISQLConnect SQLConnect)
    {
        _configurationSettings = configurationSettings;
        _someWebServiceProvider = someWebServiceProvider;
        _someOtherWebProvider = someOtherWebProvider;
        _dB2Connect = dB2Connect;
        _dB2SomeOtherData = dB2SomeOtherData;
        _dB2DatabaseData = dB2DatabaseData;
        _sharepointServiceProvider = sharepointServiceProvider;
        _loggingProvider = loggingProvider;
        _AnotherProvider = AnotherProvider;
        _SQLConnect = SQLConnect;
    }

Almost all of the there are in other components but I need to be able to use them in the main application and mock them in unit tests.

Here is how one of the methods is laid out.

public ExpectedResponse GetAccountData(string AccountNumber)
    {
          // Get Needed Config Settings
          ...
          // Do some data validation before processing data
          ...
          // Try to retrieve data for DB2
          ...
          // Try to retrieve data for Sharepoint
          ...
          // Map data to response.
          ...
          // If error, handle it and write error to log
    }

Other methods are very similar but they may be reaching out to SQL Server or one or more web services.

Ideally what I would like to have is an example of an application that needs a lot of dependencies, that has unit tests, and avoids having to keep adding a new dependency to the constructor causing you to update all your unit tests just to add the new parameter.

Thanks

Answer 1

Not sure if this helps, but I came up with a pattern I called GetTester that wraps the constructor and makes handling the parameters a little easier. Here's an example:

 private SmartCache GetTester(out Mock<IMemoryCache> memory, out Mock<IRedisCache> redis)
 {
     memory = new Mock<IMemoryCache>();
     redis = new Mock<IRedisCache>();
     return new SmartCache(memory.Object, redis.Object);
 }

Callers look like this if they need all the mocks:

 SmartCache cache = GetTester(out Mock<IMemoryCache> memory, out Mock<IRedisCache> redis);

Or like this if they don't:

 SmartCache cache = GetTester(out _, out _);

These still break if you have constructor changes, but you can create overloads to minimize the changes to tests. It's a hassle but easier than it would otherwise be.

Answer 2

So possibly your classes might be doing too much. If you're finding that you're constantly increasing the work that a class is doing and as a result are needing to provide additional objects to assist in those additional tasks then this is probably the issue and you need to consider breaking up the work.

However, if this isn't the case then another option is to have the classes take in a reference to a dependency class that provides access to either the instantiated concrete objects that implement your various interfaces or instantiated factory objects which can be used to construct objects. Then instead of constantly passing new parameters you can just pass the single object and from there pull or create objects as necessary from that.