11

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

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 绑定到这个特定的方面。

4

2 回答 2

15

各个类应尽可能不受基础设施的影响——诸如 , 之类的构造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));
    }
}

这是一个很好的模式，因为每个子系统都有一个独立的配置，可以在一个地方读取。这里唯一的好处是更明显的意图。但是，对于非string值或复杂模式，我们可以让System.Configuration繁重的工作。

于 2010-08-28T20:40:09.760 回答
2

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

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

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

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

使用ninject，对于您的主项目，您可以声明您希望任何依赖于的类IAppSettings使用您的基础类的单例实例，AppSettings而不必显式地将其传递给任何地方的构造函数。

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

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

于 2010-08-28T11:23:01.667 回答