使用简单的注入器基于调用链动态注入依赖

Question

在我的应用程序中，我想使用我的 DI 容器 Simple Injector 构建以下对象图：

new Mode1(
    new CommonBuilder(
        new Grouping(
            new GroupingStrategy1())), // NOTE: Strategy 1
    new CustomBuilder());

new Mode2(
    new CommonBuilder(
        new Grouping(
            new GroupingStrategy2())), // NOTE: Strategy 2
    new CustomBuilder());

以下类代表上图：

public class Mode1 : IMode
{
    private readonly ICommonBuilder commonBuilder;
    private readonly ICustomBuilder customBuilder;

    public Mode1(ICommonBuilder commonBuilder, ICustomBuilder ICustomBuilder customBuilder)
    {
        this.commonBuilder = commonBuilder;
        this.customBuilder = customBuilder;
    }

    public void Run()
    {
        this.commonBuilder.Build();
        this.customBuilder.Build();

        //some code specific to Mode1
    }
}

public class Mode2 : IMode
{
    //same code as in Mode1

    public void Run()
    {
        this.commonBuilder.Build();
        this.customBuilder.Build();

        //some code specific to Mode2
    }
}

CommonBuilder 和 Grouping 是：

public class CommonBuilder : ICommonBuilder
{
    private readonly IGrouping grouping;

    public CommonBuilder(IGrouping grouping)
    {
        this.grouping = grouping;
    }

    public void Build()
    {
        this.grouping.Group();
    }

}

public class Grouping : IGrouping
{
    //Grouping strategy should be binded based on mode it is running
    private readonly IGroupingStrategy groupingStrategy;

    public Grouping(IGroupingStrategy groupingStrategy)
    {
        this.groupingStrategy = groupingStrategy;
    }

    public void Group()
    {
        this.groupingStrategy.Execute();
    }
}

我在我的项目中使用 Simple Injector for DI。如上所示，我采用了 2 种代码模式，根据用户偏好调用，每种模式都有通用代码（我不想复制），我想绑定我的分组策略（I'我根据执行模式在我的通用代码中采用了 2 种分组策略，每种模式一个）。我遇到了使用工厂并在运行时在绑定之间切换的解决方案，但我不想使用该解决方案，因为我在代码中的多个位置都有相同的场景（我最终会创建多个工厂）。

谁能建议如何以更简洁的方式进行绑定

Answer 1

您可以使用Context-Based Injection。但是，因为基于依赖的消费者（或他们父母的父母）的消费者的基于上下文的注入可能会导致各种复杂性和微妙的错误（尤其是在涉及缓存生活方式时，例如Scoped和Singleton）， Simple Injector 的 API 限制您向上查找。

有几种方法可以解决 Simple Injector 中的这个看似限制的问题。您应该做的第一件事是退后一步，看看您是否可以简化您的设计，因为这些类型的需求通常（但不总是）来自设计效率低下。其中一个问题是Liskov Substitution Principle (LSP) 违规。从这个角度来看，最好问自己一个问题，当Mode1 被注入包含Mode2 策略的Grouping 时会中断吗？如果答案是肯定的，那么您很可能违反了 LSP，您应该首先尝试解决该问题。修复后，您可能会看到配置问题也消失了。

如果您确定设计不违反 LSP，则次优选择是将有关消费者的消费者的类型信息直接刻录到图表中。这是一个简单的例子：

var container = new Container();

container.Collection.Append<IMode, Mode1>();
container.Collection.Append<IMode, Mode2>();

container.RegisterConditional(
    typeof(ICommonBuilder),
    c => typeof(CommonBuilder<>).MakeGenericType(c.Consumer.ImplementationType),
    Lifestyle.Transient,
    c => true);

container.RegisterConditional(
    typeof(IGrouping),
    c => typeof(Grouping<>).MakeGenericType(c.Consumer.ImplementationType),
    Lifestyle.Transient,
    c => true);

container.RegisterConditional<IGroupingStrategy, Strategy1>(
    c => typeof(Model1) == c.Consumer.ImplementationType
        .GetGenericArguments().Single() // Consumer.Consumer
            .GetGenericArguments().Single(); // Consumer.Consumer.Consumer

container.RegisterConditional<IGroupingStrategy, Strategy2>(
    c => typeof(Mode2)) == c.Consumer.ImplementationType
        .GetGenericArguments().Single()
            .GetGenericArguments().Single();

在此示例中，不是使用非泛型 Grouping 类，而是创建了一个新的 Grouping<T> 类，CommonBuilder<T> 也是如此。这些类可以是非泛型 Grouping 和 CommonBuilder 类的子类，放置在您的 Composition Root 中，因此您不必为此更改应用程序代码：

class Grouping<T> : Grouping // inherit from base class
{
    public Grouping(IGroupingStrategy strategy) : base(strategy) { }
}

class CommonBuilder<T> : CommonBuilder // inherit from base class
{
    public CommonBuilder(IGrouping grouping) : base(grouping) { }
}

使用这个通用的CommonBuilder<T>,1 进行注册，其中T 成为它被注入的消费者的类型。换句话说，Mode1 将被注入 CommonBuilder<Mode1>，Mode2 将获得 CommonBuilder<Mode2>。这与将ILogger 实现注册为shown in the documentation 时的常见情况相同。但是，由于是通用类型，CommonBuilder<Mode1> 将被注入 Grouping<CommonBuilder<Mode1>>。

这些注册并不是真正有条件的，而是上下文相关的。注入的类型会根据其使用者而变化。然而，这个构造使得IGrouping 的消费者的类型信息在构造的对象图中可用。这允许基于该类型信息应用IGroupingStrategy 的条件注册。这就是注册谓词内部发生的情况：

c => typeof(Mode2)) == c.Consumer.ImplementationType // = Grouping<CommonBuilder<Mode2>>
    .GetGenericArguments().Single() // = CommonBuilder<Mode2>
        .GetGenericArguments().Single(); // = Mode2

换句话说，如果我们可以更改IGrouping 实现，使其实现类型（Grouping<T>）提供有关其消费者（IMode 实现）的信息。这样IGroupingStrategy 的条件注册就可以使用有关其消费者的消费者的信息。

这里注册请求消费者的实现类型（将是Grouping<Mode1> 或Grouping<Mode2>）并将从该实现中获取单个通用参数（将是Mode1 或Mode2）。换句话说，这允许我们获取消费者的消费者。这可以与预期类型匹配以返回true 或false。

虽然这看起来有点笨拙和复杂，但这个模型的优点是完整的对象图对于 Simple Injector 是已知的，这允许它分析和验证对象图。它还允许进行自动接线。换句话说，如果IGrouping 或IGroupingStrategy 实现有（其他）依赖关系，Simple Injector 将自动注入它们并验证它们的正确性。它还允许您在不丢失任何信息的情况下可视化对象图。例如，如果您将鼠标悬停在 Visual Studio 调试器中，Simple Injector 将显示以下图表：

Mode1(
    CommonBuilder<Mode1>(
        Grouping<CommonBuilder<Mode1>>(
            Strategy1())))

这种方法的明显缺点是，如果CommonBuilder<T> 或Grouping<T> 被注册为单例，现在每个封闭泛型类型将有一个实例。这意味着CommonBuilder<Mode1> 将是与CommonBuilder<Mode2> 不同的实例。

或者，您也可以将CommonBuilder 注册为有条件的，如下所示：

var container = new Container();

container.Collection.Append<IMode, Mode1>();
container.Collection.Append<IMode, Mode2>();

container.RegisterConditional<ICommonBuilder>(
    Lifestyle.Transient.CreateRegistration(
        () => new CommonBuilder(new Grouping(new Strategy1())),
        container),
    c => c.Consumer.ImplementationType == typeof(Mode1));

container.RegisterConditional<ICommonBuilder>(
    Lifestyle.Transient.CreateRegistration(
        () => new CommonBuilder(new Grouping(new Strategy2())),
        container),
    c => c.Consumer.ImplementationType == typeof(Mode2));

这比以前的方法简单一些，但它禁用了自动连线。在这种情况下，CommonBuilder 及其依赖项是手动连接的。当对象图很简单（不包含很多依赖项）时，这种方法就足够了。但是，当将依赖项添加到 CommonBuilder、Grouping 或策略时，这可能会导致高维护并可能隐藏错误，因为 Simple Injector 将无法代表您验证依赖关系图。

请注意文档中有关RegisterConditional 方法的以下声明：

谓词仅在对象图编译期间使用，谓词的结果被烧录在返回的对象图结构中。对于请求的类型，将在每次后续调用中创建完全相同的图表。这不允许根据运行时条件更改图表。