Question

以下方法将配置信息注入新构造的实例有哪些优点/缺点？你会用哪个？

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

选项一：

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);

选项二：

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);

感谢所有想法。

Answer 1

取决于，

如果IApplicationConfiguration仅包含与DailyFilePathProvider相关的配置，我会选择第二个选项。如果它包含应用程序其他部分的配置，您可能会认为这是“关注点分离”。在这种情况下，更好的选择是将属性IDailyFilePathProviderCfg添加到IApplicationConfiguration，其中包含专门针对DailyFilePathProvider的配置。通过这种方式，您可以获得两个方面的最佳效果，您只需注入相关数据，例如选项一，但代码也很容易维护，就像在选项二中一样。

我个人认为应用程序范围的配置最好在静态类中抽象出来所以代码的所有部分都可以轻松访问设置。

这个问题的答案很大程度上取决于个人编程风格。它还取决于您正在构建的应用程序的类型和大小。就个人而言，我不想在构造函数中注入更多内容，而不是在构建对象时需要注入更多内容。

Answer 2

我对类似问题的回答可能会提供一些见解：

Dependency Injection and AppSettings

要点是Confguration接口是管道，它在消耗它的类中不添加语义值。还有一个如何构建应用程序的示例，以便可以轻松地传播这些值。答案被标记为问题的答案。

Answer 3

我更喜欢选项2，因此我可以轻松添加更多设置而无需更改ctor。我也会把它换成......

class DailyFilePathProvider {
    private readonly IApplicationConfiguration configuration;

Answer 4

第一个代码仅使用某种依赖注入来解析要使用的配置，但在构造DailyFilePathProvider时它不使用依赖注入。

所以我会选择第二个选项，你真正将配置注入DailyFilePathProvider。

以下是一些以NInject为例的模式：Injection patterns

依赖注入设计问题

4 个答案: