构造函数注入与 IocFactory

Question

今天上班和同事讨论了以下问题：

基本上我们有一个规则引擎，其工作方式如下：

规则执行器

获取所有要在构造函数中执行的规则，如public RuleExecutor(ICollection<IRule> rulesToExecute) { ... }
通过为每个 rulesToExecute

rule.ApplyRule();

规则

提供方法ApplyRule()；执行规则

现在我们希望 RuleExecutor 在 cron 作业中执行。

我们讨论了如何检索 RuleExecutor 的实例。

我认为 "correct way" 是通过构造函数注入

public RuleCronJob(IRuleExecutor ruleExecutor) { ... }

我的同事想使用 "IocFactory"，它有一个静态方法 GetInstance<>。因此，在 cron 作业的 "execute method" 中，他会做类似 var ruleExecutor = IocFactory.GetInstance<IRuleExecutor>();

的事情

public static TType GetInstance<TType>(params Tuple<string, object>[] constructorParameters)
    {
        if (constructorParameters.Any())
        {
            var constructorArgs = new Collection<ConstructorArgument>();
            foreach (var parameter in constructorParameters)
            {
                constructorArgs.Add(new ConstructorArgument(parameter.Item1, parameter.Item2, true));
            }

            return Kernel.Value.Get<TType>(constructorArgs.Cast<IParameter>().ToArray());
        }

        return Kernel.Value.Get<TType>();
    }

内核是 Ninject 的标准内核。

我认为构造函数注入更好，因为它允许更简单的测试（模拟），IocFactory 实际上是一个 "ServiceLocator"，我认为这是一个反模式，IocFactory 向 cronjob 添加了另一个依赖项，这不是'没必要...但我无法说服他使用它，因为他认为 IocFactory "works as well so why not use it"...

说服他使用构造函数注入而不是 IocFactory 的理由是什么？

提前致谢

Answer 1

This 是您如何回答他的 "works well"（非技术）论点。

如果有的话，他使用 params Tuple<string, object> 的方法充其量是可怕的：维护噩梦，重构工具的零支持。服务定位器实际上是变相的单例。

使用适当的 IoC，您可以利用您选择的容器提供的任何高级功能：不同的生命周期、构造函数和属性注入、对 Func<> 和 Lazy<> 的支持等。使用服务定位器，你得到 none 个。

构造函数注入与 IocFactory

Constructor Injection vs IocFactory

.net

c#

dependency-injection

inversion-of-control