c# - 使用简单的注入(inject)器基于调用链动态注入(inject)依赖

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();
    }
}

我在项目中使用用于DI的Simple Injector。如上所示，我已经按照用户偏好选择了两种代码模式，每种模式都有通用代码（我不想重复），我想绑定分组策略（ ve根据执行模式在我的通用代码中采用2种分组策略，每种模式一种。我遇到了使用工厂并在运行时在绑定之间切换的解决方案，但是我不想使用该解决方案，因为我在代码中的多个地方都有相同的场景（我将最终创建多个工厂） 。

任何人都可以建议如何以更清洁的方式进行绑定

Answer 1

您可以使用Context-Based Injection。但是，由于基于依存者的消费者（或其父母的父母）的消费者进行的基于上下文的注入会导致各种并发症和细微的错误（尤其是当涉及缓存诸如Scoped和Singleton的生活方式时）， Simple Injector的API限制您向上一级查找。

有几种方法可以解决Simple Injector中的这种看似限制。您应该做的第一件事是退后一步，看看您是否可以简化设计，因为这类要求经常（但并非总是）来自设计效率低下。这样的问题之一就是Liskov Substitution Principle（LSP）违规。从这个角度来看，最好问自己一个问题：Mode1在注入包含Grouping策略的Mode2时会中断吗？如果答案是肯定的，则可能是您违反了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类的子类，因此您不必为此更改应用程序代码：

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>进行注册，其中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方法的文档中的以下声明：


  谓词仅在对象图编译期间使用，并且谓词的结果会在返回的对象图的结构中燃烧。对于请求的类型，将在每个后续调用中创建完全相同的图。这不允许基于运行时条件更改图形。