带有 IOC 容器的策略设计模式 - 特别是 Ninject答案

【问题标题】：Strategy Design pattern with IOC containers - Ninject specifically带有 IOC 容器的策略设计模式 - 特别是 Ninject
【发布时间】：2011-01-24 11:01:53
【问题描述】：

我有一个需要使用策略设计模式的类。在运行时，我需要切换不同的算法来查看对应用程序性能的影响。

当前有问题的类在构造函数中有四个参数，每个参数代表一个算法。

如何使用 Ninject（或通用方法）我仍然可以使用 IOC 但使用策略模式？

当前的限制是我的内核（容器）知道每个算法接口，但只能绑定到一个具体的类。目前我能看到的唯一解决方法是在构建时传入所有八种算法，但使用不同的接口，但这似乎完全没有必要。如果我不使用 IOC 容器，我不会这样做，所以一定有办法解决这个问题。

代码示例：

class MyModule : NinjectModule 
{
    public override void Load() 
    {
        Bind<Person>().ToSelf();
        Bind<IAlgorithm>().To<TestAlgorithm>();
        Bind<IAlgorithm>().To<ProductionAlgorithm>();
    }
}

Person 需要同时使用这两种算法，这样我才能在运行时切换。但只有 TestAlgorithm 是绑定的，因为它是容器中的第一个。

【问题讨论】：

标签： c# design-patterns ioc-container ninject strategy-pattern

【解决方案1】：

如果您需要在运行时更改 IAlgorithm 实现，您可以更改 Person 以要求算法工厂，该算法根据运行时条件提供不同的具体算法。 p>

一些依赖注入容器允许您绑定到匿名创建委托 - 如果 Ninject 支持，您可以将决策逻辑放入其中之一。

【讨论】：

【解决方案2】：

让我们退后一步，看看更大的图景。由于您希望能够在运行时切换策略，因此必须有某种信号机制告诉 Person 切换策略。如果您的应用程序是 UI 驱动的，也许有一个按钮或下拉列表，用户可以在其中选择要使用的策略，但即使不是这种情况，某些外部调用者也必须 map 一块将运行时数据传输到策略实例。

standard DI solution when you need to map a run-time instance to a dependency is to use an Abstract Factory。

您无需在容器中注册各个 Strategies，而是注册工厂。

完全可以编写一个完整的API，使其成为DI-friendly, but still DI Container-agnostic。

【讨论】：