Question

今天在工作中，一位同事和我讨论了以下问题：

基本上我们有一个规则引擎，它按以下方式工作：

RuleExecutor

获取在public RuleExecutor(ICollection<IRule> rulesToExecute) { ... }
通过为每个rulesToExecute调用rule.ApplyRule();来执行所有规则

规则

提供方法ApplyRule（）;执行规则

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

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

我认为“正确的方法”是通过构造函数注入

public RuleCronJob(IRuleExecutor ruleExecutor) { ... }

我的同事想要使用具有静态方法GetInstance＆lt;＆gt;的“IocFactory”。因此，在cron作业的“执行方法”中，他会执行类似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的StandardKernel。

我认为构造函数注入更好，因为它允许更容易的测试（模拟），IocFactory实际上是一个“ServiceLocator”，我认为是反模式，IocFactory添加另一个依赖于cronjob，这是不必要的..但是我不能说服他使用它，因为他认为IocFactory“也能正常工作，所以为什么不使用它”......

说服他使用构造函数注入而不是IocFactory会有什么争论？

提前致谢

Answer 1

This就是如何回答他的＆＃34;效果很好＆＃34; （和非技术性的）论点。

如果有的话，他对params Tuple<string, object>的态度充其量是可怕的：维护噩梦，重构工具的零支持。 Service Locator实际上是伪装的Singleton。

使用适当的IoC，您可以提供您选择的容器提供的任何高级功能：不同的生命周期，构造函数和属性注入，对Func<>和Lazy<>的支持等。使用Service Locator，您不会得到任何这一点。

构造函数注入与IocFactory

1 个答案: