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

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 和IDependencies 一样有意义。大的构造函数表明一个类有太多的责任，不管参数是原始的还是复杂的。

考虑像对待任何其他依赖项一样对待 int、string 和 bool。它会让你的课程更简洁、更专注、更能抵抗变化，并且更容易进行单元测试。

Answer 2

需要认识到的重要部分是，配置只是驱动应用程序行为的多种价值来源之一。

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

如果您仍想从配置文件中读取值，您可以从应用程序的Composition Root 中执行此操作。使用 StructureMap，它可能看起来像这样：

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

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

Answer 3

一种方法是像您发布的那样注入配置接口。以下是其他几种方法。

暴露二传手

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 容器（也包括结构图）将 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 文件中提取了大部分内容，并且其中还有一些硬编码值。

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

另一种方法是执行服务定位器类型模式，您可以在其中要求依赖注入容器即时为您获取配置类的实例。服务位置is considered an anti-pattern generally，但可能仍然对您有用。