依赖注入和AppSettings

Question

假设我正在为我的应用程序定义一个浏览器实现类：

class InternetExplorerBrowser : IBrowser {
    private readonly string executablePath = @"C:\Program Files\...\...\ie.exe";

    ...code that uses executablePath
}

乍一看，这似乎是一个好主意，因为 executablePath 数据靠近将使用它的代码。

当我尝试在另一台具有外语操作系统的计算机上运行相同的应用程序时，问题就出现了：executablePath 将具有不同的值。

我可以通过 AppSettings 单例类（或其等效类之一）来解决这个问题，但没有人知道我的类实际上依赖于这个 AppSettings 类（这违背了 DI 想法）。它也可能给单元测试带来困难。

我可以通过构造函数传入 executablePath 来解决这两个问题：

class InternetExplorerBrowser : IBrowser {
    private readonly string executablePath;

    public InternetExplorerBrowser(string executablePath) {
        this.executablePath = executablePath;
    }
}

但这会在我的 Composition Root 中引发问题（启动方法将完成所有需要的类接线），然后该方法必须知道如何连接事物，并且必须知道所有这些小设置数据：

class CompositionRoot {
    public void Run() {
        ClassA classA = new ClassA();

        string ieSetting1 = "C:\asdapo\poka\poskdaposka.exe";
        string ieSetting2 = "IE_SETTING_ABC";
        string ieSetting3 = "lol.bmp";

        ClassB classB = new ClassB(ieSetting1);
        ClassC classC = new ClassC(B, ieSetting2, ieSetting3);

        ...
    }
}

这很容易变得一团糟。

我可以通过将表单的接口传递

interface IAppSettings {
    object GetData(string name);
}

给所有需要某种设置的类来解决这个问题。然后，我可以将其实现为嵌入了所有设置的常规类，也可以将其实现为从 XML 文件读取数据的类，类似的东西。如果这样做，我应该为整个系统提供一个通用的 AppSettings 类实例，还是为每个可能需要的类关联一个 AppSettings 类？这确实看起来有点矫枉过正。此外，将所有应用程序设置放在同一位置可以轻松查看并了解在尝试将程序移动到不同平台时需要进行的所有更改。

处理这种常见情况的最佳方法是什么？

编辑：

那么使用 IAppSettings 并将其所有设置硬编码在其中怎么样？

interface IAppSettings {
    string IE_ExecutablePath { get; }
    int IE_Version { get; }
    ...
}

这将允许编译时类型安全。如果我看到接口/具体类增长太多，我可以创建其他较小的 IMyClassXAppSettings 形式的接口。对于中型/大型项目来说，这会是一个沉重的负担吗？

我还阅读了有关 AOP 及其处理横切关注点的优势（我想这就是其中之一）。难道它不能也为这个问题提供解决方案吗？也许像这样标记变量：

class InternetExplorerBrowser : IBrowser {
    [AppSetting] string executablePath;
    [AppSetting] int ieVersion;

    ...code that uses executablePath
}

然后，在编译项目时，我们还具有编译时安全性（让编译器检查我们是否实际实现了会编织数据的代码。当然，这会将我们的 API 与这个特定方面联系起来。

Answer 1

各个类应尽可能不受基础设施的影响 - 像 IAppSettings、IMyClassXAppSettings 和 [AppSetting] 这样的构造将组合详细信息传递给类，这些类，最简单的情况是，实际上只依赖于原始值，例如 executablePath。依赖注入的艺术在于关注点的分解。

我已经使用 Autofac 实现了这个确切的模式，它具有与 Ninject 类似的模块，并且应该产生类似的结果代码（我意识到这个问题没有提到 Ninject，但 OP 在评论中提到了）。

模块按子系统组织应用程序。模块公开子系统的可配置元素：

public class BrowserModule : Module
{
    private readonly string _executablePath;

    public BrowserModule(string executablePath)
    {
        _executablePath = executablePath;
    }

    public override void Load(ContainerBuilder builder)
    {
        builder
            .Register(c => new InternetExplorerBrowser(_executablePath))
            .As<IBrowser>()
            .InstancePerDependency();
    }
}

这使组合根面临同样的问题：它必须提供 executablePath 的值。为了避免配置混乱，我们可以编写一个独立的模块来读取配置设置并将其传递给 BrowserModule：

public class ConfiguredBrowserModule : Module
{
    public override void Load(ContainerBuilder builder)
    {
        var executablePath = ConfigurationManager.AppSettings["ExecutablePath"];

        builder.RegisterModule(new BrowserModule(executablePath));
    }
}

您可以考虑使用自定义配置部分而不是 AppSettings；更改将本地化到模块：

public class BrowserSection : ConfigurationSection
{
    [ConfigurationProperty("executablePath")]
    public string ExecutablePath
    {
        get { return (string) this["executablePath"]; }
        set { this["executablePath"] = value; }
    }
}

public class ConfiguredBrowserModule : Module
{
    public override void Load(ContainerBuilder builder)
    {
        var section = (BrowserSection) ConfigurationManager.GetSection("myApp.browser");

        if(section == null)
        {
            section = new BrowserSection();
        }

        builder.RegisterModule(new BrowserModule(section.ExecutablePath));
    }
}

这是一个很好的模式，因为每个子系统都有一个独立的配置，可以在单个位置读取。这里唯一的好处是意图更明显。不过，对于非字符串值或复杂模式，我们可以让 System.Configuration 来完成繁重的工作。

Answer 2

我会选择最后一个选项 - 传入一个符合 IAppSettings 接口的对象。事实上，我最近在工作中进行了重构，以整理一些单元测试，并且效果很好。但是，很少有类依赖于该项目中的设置。

我会创建设置类的单个实例，并将其传递给依赖于它的任何东西。我看不出这有什么根本问题。

但是，我认为您已经考虑过这一点，并了解如果您有很多依赖于设置的类，这会是多么痛苦。

如果这对您来说是个问题，您可以使用依赖注入框架来解决它，例如 ninject （抱歉，如果您已经知道像 ninject 这样的项目 - 这可能听起来有点居高临下 - 如果你不熟悉，为什么使用 ninject github 上的部分是一个学习的好地方）。

使用 ninject，对于您的主项目，您可以声明您希望任何依赖于 IAppSettings 的类使用基于 AppSettings 的类的单例实例，而无需显式传递它到各地的建设者那里。

然后，您可以通过声明要在使用 IAppSettings 的地方使用 MockAppSettings 的实例，或者通过简单地显式传递模拟对象来为单元测试设置不同的系统直接地。

我希望我已经正确理解了你的问题的要点并且我已经提供了帮助 - 你听起来已经知道你在做什么了:)