使用依赖注入将配置代码排除在逻辑代码之外的方法

Question

如何使用设置（ApplicationSettingsBase）和依赖注入将所有配置文件代码保留在我的逻辑代码之外？

我所说的配置是指客户特定的配置文件。

我真的必须在每次需要时注入配置类还是还有其他模式？

如果能得到一些示例代码那就太好了！

示例：

静态配置：

public static class StaticConfiguration
{
    public static bool ShouldApplySpecialLogic { get; set; }
    public static string SupportedFileMask { get; set; }
}

public class ConsumerOfStaticConfiguration
{
    public void Process()
    {
        if (StaticConfiguration.ShouldApplySpecialLogic)
        {
            var strings = StaticConfiguration.SupportedFileMask.Split(',');
            foreach (var @string in strings)
            {

            }
        }
    }
}

非静态配置：

public interface IConfiguration
{
    bool ShouldApplySpecialLogic { get; set; }
    string SupportedFileMask { get; set; }
}

public class Configuration : IConfiguration
{
    public bool ShouldApplySpecialLogic { get; set; }
    public string SupportedFileMask { get; set; }
}

public class Consumer
{
    private readonly IConfiguration _configuration;

    public Consumer(IConfiguration configuration)
    {
        _configuration = configuration;
    }

    public void Process()
    {
        if (_configuration.ShouldApplySpecialLogic)
        {
            var strings = _configuration.SupportedFileMask.Split(',');
            foreach (var @string in strings)
            {

            }
        }
    }
}

具有非静态配置的静态上下文：

public static class Context
{
    public static IConfiguration Configuration { get; set; }
}

public class ConsumerOfStaticContext
{
    public void Process()
    {
        if (Context.Configuration.ShouldApplySpecialLogic)
        {
            var strings = Context.Configuration.SupportedFileMask.Split(',');
            foreach (var @string in strings)
            {

            }
        }
    }
}

Answer 1

配置类降低了消费者的内聚性并增加了耦合性。这是因为可能有许多设置与您的类所需的一两个设置无关，但为了满足依赖性，您的 IConfiguration 实现必须为所有访问器提供值，甚至是不相关的。

它还将您的类与基础设施知识结合起来：诸如“这些值配置在一起”之类的详细信息从应用程序配置中渗透到您的类中，从而增加了受不相关系统更改影响的表面积。

共享配置值的最简单、最灵活的方法是使用值本身的构造函数注入，从而外部化基础设施问题。然而，在对另一个答案的评论中，您表示您害怕拥有大量构造函数参数，这是一个合理的担忧。

需要认识到的关键点是原始依赖关系和复杂依赖关系之间没有区别。无论您依赖于整数还是接口，它们都是您不知道但必须被告知的事情。从这个角度来看，IConfiguration 与 IDependency 一样有意义。大型构造函数表明一个类有太多的责任，无论参数是原始的还是复杂的。

考虑像对待任何其他依赖项一样对待 int、string 和 bool。它将使你的类更清晰、更集中、更能抵抗变化，并且更容易进行单元测试。

Answer 2

需要认识到的重要一点是，配置只是驱动应用程序行为的多个值源之一。

第二个选项（非静态配置）是最好的，因为它使您能够将使用者与配置值的来源完全解耦。但是，该接口不是必需的，因为配置设置通常最好建模为值对象。

如果您仍想从配置文件中读取值，可以从应用程序的 组合根。使用 StructureMap，它可能看起来像这样：

var config = (MyConfigurationSection)ConfigurationManager.GetSection("myConfig");

container.Configure(r => r
    .For<Consumer>()
    .Ctor<MyConfigurationSection>()
    .Is(config));

Answer 3

一种方法是像您发布的那样注入配置接口。这里还有其他一些方法。

公开 Setter

class Consumer
{
    public bool ShouldApplySpecialLogic { get; set; }

    ...
}

在组合根中，您可以读取配置文件或对其进行硬编码。 Autofac 示例：

builder.RegisterType<Consumer>().AsSelf()
    .OnActivated(e => e.Instance.ShouldApplySpecialLogic = true);

时，这可能才是可取的：

有一个良好的默认构造函数注入

public class Server
{
    public Server(int portToListenOn) { ... }
}

只有当您在组合根中

builder.Register(c => new Server(12345)).AsSelf();

Answer 4

在我的应用程序中，我使用 IoC 执行了您上面所做的操作。也就是说，让我的 IoC 容器（也包括 StructureMap）将 IApplicationSettings 注入到我的类中。

例如，在 ASP.NET MVC3 项目中，它可能如下所示：

Public Class MyController
    Inherits Controller

    ...
    Private ReadOnly mApplicationSettings As IApplicationSettings

    Public Sub New(..., applicationSettings As IApplicationSettings)
        ...
        Me.mApplicationSettings = applicationSettings
    End Sub

    Public Function SomeAction(custId As Guid) As ActionResult
         ...

         ' Look up setting for custId
         ' If not found fall back on default like
         viewModel.SomeProperty = Me.mApplicationSettings.SomeDefaultValue

         Return View("...", viewModel)
    End Function
End Class

我的 IApplicationSettings 实现从应用程序的 .config 文件中提取大部分内容，并具有一些硬编码值也在那里。

我的示例不是逻辑流控制（就像您的示例一样），但如果是的话，它的工作原理是一样的。

另一种方法是使用服务定位器类型模式，在这种模式中，您要求依赖注入容器即时获取配置类的实例。 Service-Location 通常被视为反模式，但仍可能是对你有用。