使用简单的注入器基于调用链动态注入依赖
Inject dependency dynamically based on call chain using simple injector
在我的应用程序中，我想使用我的 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 种代码模式，根据用户偏好调用，我有每种模式的通用代码（我不想重复），我想绑定我的分组策略（我'根据执行模式，在我的通用代码中采用了 2 种分组策略，每种模式一种）。我遇到过使用工厂的解决方案，在运行时间在绑定之间切换，但我不想使用该解决方案，因为我在多个场景中遇到相同的情况放在我的代码中（我最终会创建多个工厂）。
谁能建议如何以更简洁的方式进行绑定
您可以使用 Context-Based Injection。然而，因为基于依赖消费者的消费者（或他们的 parents 的 parents）的 context-based 注入会导致各种复杂情况和细微的错误（尤其是在缓存生活方式时，例如 Scoped 和 Singleton），Simple Injector 的 API 将您限制为向上看一级。
有几种方法可以解决 Simple Injector 中这个看似存在的限制。你应该做的第一件事是退后一步，看看你是否可以简化你的设计，因为这些类型的需求通常（但不总是）来自设计效率低下。其中一个问题是 Liskov Substitution Principle (LSP) 违规。从这个角度来看，最好问问自己这个问题，当注入包含 Mode2 策略的 Grouping 时，Mode1 会中断吗？如果答案是肯定的，您可能违反了 LSP，您应该首先尝试解决该问题。修复后，您可能会发现配置问题也会消失。
如果您确定设计不违反 LSP，second-best 选项是将有关消费者的消费者的类型信息直接刻录到图中。这是一个简单的例子：
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();
在此示例中，没有使用 non-generic Grouping class，而是创建了一个新的 Grouping<T> class，对CommonBuilder<T>。这些 class 可以是 non-generic Grouping 和 CommonBuilder class 的子 class，放置在您的 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 的消费者的类型信息在构造的 object 图中可用。这允许根据该类型信息应用 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）。换句话说，这使我们能够获得消费者的消费者。这可以与 return 或 true 或 false.
的预期类型匹配
虽然这看起来有点笨拙和复杂，但这个模型的优点是完整的 object 图对于 Simple Injector 是已知的，这允许它分析和验证 object 图。它还允许 Auto-Wiring 发生。换句话说，如果 IGrouping 或 IGroupingStrategy 实现具有（其他）依赖项，Simple Injector 将自动注入它们并验证它们的正确性。它还允许您在不丢失任何信息的情况下可视化 object 图形。例如，如果您在 Visual Studio 调试器中将鼠标悬停在它上面，Simple Injector 将显示以下图表：
Mode1(
CommonBuilder<Mode1>(
Grouping<CommonBuilder<Mode1>>(
Strategy1())))
这种方法的明显缺点是，如果 CommonBuilder<T> 或 Grouping<T> 被注册为单例，现在每个 closed-generic 类型将有一个实例。这意味着 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));
这比以前的方法简单一些，但它禁用了 Auto-Wiring。在这种情况下 CommonBuilder 及其依赖项是手动连接的。当 object 图很简单（不包含很多依赖项）时，此方法就足够了。但是，当将依赖项添加到 CommonBuilder、Grouping 或策略时，这可能会导致高维护成本并可能隐藏错误，因为 Simple Injector 将无法代表您验证依赖关系图。
请注意文档中有关 RegisterConditional 方法的以下声明：
The predicates are only used during object graph compilation and the predicate’s result is burned in the structure of returned object graph. For a requested type, the exact same graph will be created on every subsequent call. This disallows changing the graph based on runtime conditions.
在我的应用程序中，我想使用我的 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 种代码模式，根据用户偏好调用，我有每种模式的通用代码（我不想重复），我想绑定我的分组策略（我'根据执行模式，在我的通用代码中采用了 2 种分组策略，每种模式一种）。我遇到过使用工厂的解决方案，在运行时间在绑定之间切换，但我不想使用该解决方案，因为我在多个场景中遇到相同的情况放在我的代码中（我最终会创建多个工厂）。
谁能建议如何以更简洁的方式进行绑定
您可以使用 Context-Based Injection。然而，因为基于依赖消费者的消费者（或他们的 parents 的 parents）的 context-based 注入会导致各种复杂情况和细微的错误（尤其是在缓存生活方式时，例如 Scoped 和 Singleton），Simple Injector 的 API 将您限制为向上看一级。
有几种方法可以解决 Simple Injector 中这个看似存在的限制。你应该做的第一件事是退后一步，看看你是否可以简化你的设计，因为这些类型的需求通常（但不总是）来自设计效率低下。其中一个问题是 Liskov Substitution Principle (LSP) 违规。从这个角度来看，最好问问自己这个问题，当注入包含 Mode2 策略的 Grouping 时，Mode1 会中断吗？如果答案是肯定的，您可能违反了 LSP，您应该首先尝试解决该问题。修复后，您可能会发现配置问题也会消失。
如果您确定设计不违反 LSP，second-best 选项是将有关消费者的消费者的类型信息直接刻录到图中。这是一个简单的例子：
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();
在此示例中，没有使用 non-generic Grouping class，而是创建了一个新的 Grouping<T> class，对CommonBuilder<T>。这些 class 可以是 non-generic Grouping 和 CommonBuilder class 的子 class，放置在您的 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 的消费者的类型信息在构造的 object 图中可用。这允许根据该类型信息应用 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）。换句话说，这使我们能够获得消费者的消费者。这可以与 return 或 true 或 false.
虽然这看起来有点笨拙和复杂，但这个模型的优点是完整的 object 图对于 Simple Injector 是已知的，这允许它分析和验证 object 图。它还允许 Auto-Wiring 发生。换句话说，如果 IGrouping 或 IGroupingStrategy 实现具有（其他）依赖项，Simple Injector 将自动注入它们并验证它们的正确性。它还允许您在不丢失任何信息的情况下可视化 object 图形。例如，如果您在 Visual Studio 调试器中将鼠标悬停在它上面，Simple Injector 将显示以下图表：
Mode1(
CommonBuilder<Mode1>(
Grouping<CommonBuilder<Mode1>>(
Strategy1())))
这种方法的明显缺点是，如果 CommonBuilder<T> 或 Grouping<T> 被注册为单例，现在每个 closed-generic 类型将有一个实例。这意味着 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));
这比以前的方法简单一些，但它禁用了 Auto-Wiring。在这种情况下 CommonBuilder 及其依赖项是手动连接的。当 object 图很简单（不包含很多依赖项）时，此方法就足够了。但是，当将依赖项添加到 CommonBuilder、Grouping 或策略时，这可能会导致高维护成本并可能隐藏错误，因为 Simple Injector 将无法代表您验证依赖关系图。
请注意文档中有关 RegisterConditional 方法的以下声明：
The predicates are only used during object graph compilation and the predicate’s result is burned in the structure of returned object graph. For a requested type, the exact same graph will be created on every subsequent call. This disallows changing the graph based on runtime conditions.