SRP, DI and app.config: when to instantiate injecting classes?

Question

I'm refactoring a small report-generating application and making it adhere to the SOLID principles, etc. So, all my classes follow SRP with DI and I use app.config for most parameter variations. I'm not using any DI frameworks, yet, but rather creating all the dependency classes at the app entry point. However, that led to a design question, which I'm generalizing here:

I can create my dependencies and main reporter classes like this:

//dependencies    
var sharedDependency = new SharedDependency();

var whiteColorDependency = new ColorDependency("white");
var blueColorDependency = new ColorDependency("blue");

var config1Dependency = new MultiDependency("config1");
var config2Dependency = new MultiDependency("config2");
...
var config12Dependency = new MultiDependency("config12");



//main logic
var reporter1 = new Reporter(sharedDependency, whiteColorDependency, config1Dependency);
var reporter2 = new Reporter(sharedDependency, whiteColorDependency, config2Dependency);
var reporter3 = new Reporter(sharedDependency, whiteColorDependency, config3Dependency);
...
var reporter10 = new Reporter(sharedDependency, blueColorDependency, config10Dependency);
var reporter11 = new Reporter(sharedDependency, blueColorDependency, config11Dependency);
var reporter12 = new Reporter(sharedDependency, blueColorDependency, config12Dependency);

or like that:

foreach (var config in configs)
{
    //dependencies
    var sharedDependency = new SharedDependency();
    var colorDependency = new ColorDependency("color");
    var configDependency = new MultiDependency("config");

    //main logic
    var reporter = new Reporter(sharedDependency, colorDependency, configDependency);
    reporter.DoSomething();
}

?

(The "colors" and "config" values are all coming from the app.config file and not hard-coded. The above is generalization, as I said, and the real project has more dependencies, dependencies of dependencies, with some more shared than the others.)

The first approach is more efficient, because the CSharedDependency is created only once and CColorDependency only twice. (It's also more readable to me.) The second is fully configuration-driven, though, thus requiring zero maintenance and being fully extensible.

So, which one is the best design?

Why can't you combine both approaches? Can't you create the shared dependencies outside the loop? The question is unclear to me, because the loop alternative doesn't use `config`... — Mark Seemann, Feb 01 '16 at 07:09
@MarkSeemann The loop alternative does use `.config` for "colors" and "config" values - it's in my question. Can I create the shared dependencies outside the loop - yes, that's what method 1 is. The problem with that is that I have to explicitly specify which of the `Reporters` use `whiteColorDependency` and which ones use `blueColorDependency`. So, if I were to add another two (or five) `Reporters`, I'd have to modify the code. With the loop approach, it's all totally `.config`-driven and very extensible... But, I would have to have 12+ instances of the `ColorDependency` instead of 2. — Alex R., Feb 01 '16 at 18:35
"white", "blue" are really coming from `ConfigurationManager.AppSettings["white"]`, `ConfigurationManager.AppSettings["blue"]`. Same for "config1" through "config12". — Alex R., Feb 01 '16 at 21:29

score 3 · Answer 1 · edited May 23 '17 at 12:31

3

The correct way to organize your application for dependency injection (whether using a container or pure DI) is to use a Composition Root at the application's startup to compose your application's object graph.

Therefore, your first example looks more in line with that because you would never access your container to create dependencies at runtime, but instead inject abstract factories to create those instances.

That said, it is unclear from your example how you have organized your application. Without having a composition root you are not doing dependency injection correctly. And since you had to ask this question, I suspect you don't have a composition root because your second example would never work if you did.

References:

https://www.kenneth-truyers.net/2014/11/18/how-to-use-pure-di/

edited May 23 '17 at 12:31

Community

1
1

answered Jan 31 '16 at 05:24

NightOwl888

55,572
24
139
212

If you look at the "Pure DI in a console application" section of the reference you provided, this is exactly what I have: a console app with Pure DI and dependencies construction right there in the main(). The "entryPoint.Run()" is basically my "reporter.DoSomething()". The only difference is that I have 12 "reporters". Hence, my question - do I write an inflexible but more efficient logic for my "composition root", or a very neat one that creates unnecessary instances of shared dependencies. Your abstract factories suggestion gives me an idea, though, so I will look into it. Thx – Alex R. Feb 01 '16 at 02:36

score 3 · Answer 2 · answered Feb 02 '16 at 07:20

As far as I understand this question, the concern is that in the second alternative, SharedDependency is created multiple times, and that the ColorDependency instances, too, are created more times than necessary.

My first reaction to that is that it probably doesn't matter. If you follow the rule that constructors should do no work, creating a few objects more than necessary is most likely something that you're not going to notice - particularly if those objects subsequently engage in I/O. Object creation in .NET is fast (and I/O is slow).

That said, the 'issue' is probably easy to address.

If you wish to be fully configuration-driven, you'll need a way to distinguish between various groups of configuration values. The simplest way is most likely to prepend the appSettings keys with well-known prefixes, but a more robust approach would be to define custom configuration sections.

In any case, I'll assume that you can pull two collections out of your configuration system: colors and configs.

This should make it easy to create the Services in a configuration-driven manner:

var sharedDependency = new SharedDependency();
foreach (var color in colors)
{
    var colorDependency = new ColorDependency(color);

    foreach (var config in configs)
    {
        var configDependency = new MultiDependency(config);

        //main logic
        var reporter = new Reporter(sharedDependency, colorDependency, configDependency);
        reporter.DoSomething();
    }
}

All that said, before you start reinventing the wheel: most DI Containers support configuration via app.config, so that may also be an option for you.

And again: that said, consider whether using a DI Container is an appropriate choice after all. With text-based configuration, you lose the benefit of compile-time checking. You can also easily end up making the configuration system so complicated that code would be easier.

Unless you have a compelling reason to configure object graphs in configuration files, favour Pure DI.

SRP, DI and app.config: when to instantiate injecting classes?

2 Answers2