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或{ {1}}）。换句话说，这使我们能够吸引消费者的消费者。可以将其与期望的类型匹配以返回Mode2或true。

尽管这看起来有些尴尬和复杂，但是此模型的优点是Simple Injector知道完整的对象图，从而可以分析和验证对象图。它还允许进行自动接线。换句话说，如果false或IGrouping实现具有（其他）依赖性，则Simple Injector将自动注入它们并验证其正确性。它还允许您可视化对象图而不会丢失任何信息。例如，如果您将鼠标悬停在Visual Studio调试器中，则这是Simple Injector将显示的图形：

IGroupingStrategy

此方法的明显缺点是，如果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或策略中时，这可能会导致高维护性并可能会隐藏错误，因为Simple Injector无法代表您验证依赖关系图。

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

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

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

1 个答案: