Dependency Injection design question

What are the advantages/disadvantages of the followi开发者_如何学JAVAng approaches for injecting configuration information into a newly constructed instance? Which would you use?

interface IApplicationConfiguration {
    string SourcePath { get; }
    string DestinationPath { get; }
}

Option one:

class DailyFilePathProvider {
    private readonly string sourcePath;
    private readonly string destinationPath;
    public DailyFilePathProvider(string sourcePath, string destinationPath) {
        this.sourcePath = sourcePath;
        this.destinationPath = destinationPath;
    }
}

var configuration = container.Resolve<IApplicationConfiguration>();
var provider = new DailyFilePathProvider(configuration.SourcePath, configuration.DestinationPath);

Option two:

class DailyFilePathProvider {
    private readonly string sourcePath;
    private readonly string destinationPath;
    public DailyFilePathProvider(IApplicationConfiguration configuration) {
        this.sourcePath = configuration.SourcePath;
        this.destinationPath = configuration.DestinationPath;
    }
}

var configuration = container.Resolve<IApplicationConfiguration>();
var provider = new DailyFilePathProvider(configuration);

Thanks for all thoughts.

It depends,

I would go for option two if IApplicationConfiguration only contains configuration related to the DailyFilePathProvider. If it contains configurations for other parts of your application you might consider this 'bad separation of concerns'. In that case a better option would be to add a property IDailyFilePathProviderCfg to the IApplicationConfiguration that contains configuration specifically for the DailyFilePathProvider. That way you get best of both worlds, you only inject relevant data like in option one but the code is also easy to maintain like in option two.

Personally I think application wide configuration is best abstracted away in a static class So all parts of the code can easily access settings.

The answer to this question depends a lot on personal programming style I guess. It also depends on the type and size of application you are building. Personally I don't like to inject more in a constructor than needed for the object you are building.

This answer of mine to a similar question may provide some insight:

Dependency Injection and AppSettings

The gist is that the Confguration interface is plumbing which adds no semantic value in the class that consumes it. There is also an example of how to structure an application so these values can easily be disseminated. The answer was marked as the question's accepted answer.

I prefer option 2 so I can easily add more settings without changing the ctor. I would also switch it to...

class DailyFilePathProvider {
    private readonly IApplicationConfiguration configuration;

The first code only uses some kind of dependency injection to resolve which configuration to use, but it doesn't use dependency injection when constructing the DailyFilePathProvider.

So I would go for option number two where you actually are injecting the configuration into DailyFilePathProvider.

Here are some more about patterns with NInject as an example: Injection patterns