c# - 使用 servicelocation 而不是构造函数注入(inject)来避免编写工厂类负载是否不好

Question

现在我们使用 DI/IOC，当我们需要将额外参数传递给构造函数时，我们使用工厂类，例如

public class EmailSender 
{
    internal EmailSender(string toEmail, string subject,String body, ILogger emailLogger)
    {.....} 
}

public class EmailSenderFactory
{
    ILogger emailLogger;
    public EmailSenderFactory(ILogger emailLogger)
    { 
        this.emailLogger = emailLogger;
    }
    public EmailSender Create(string toEmail, string subject, string body) 
    {
        return new EmailSender(toEmail, subject, body, emailLogger);
    }
}

现在的问题是我们最终创建了很多工厂类，而人们并不总是知道如何使用它们(他们有时会自己新建它们)。像这样编写类的最大缺点是什么:

public class EmailSender 
{
    EmailLogger logger = IoC.Resolve<ILogger>();
    internal EmailSender(string toEmail, string subject,String body)
    {.....} 
}

优点:我们现在可以安全地使用构造函数而不需要工厂类缺点:我们必须引用服务定位器(我不担心可测试性，使用模拟容器作为容器的支持服务很容易)。

我们不应该这样做的原因有哪些？

编辑:经过一番思考，我想通过拥有一个私有(private)构造函数，并通过嵌套工厂类，我可以将实现和工厂放在一起，并防止人们不正确地创建类，所以问题已经变得有些没有实际意义了。所有关于 SL 脏的观点当然都是正确的，所以下面的解决方案让我很高兴:

public class EmailSender 
{
    public class Factory
    {
        ILogger emailLogger;
        public Factory(ILogger emailLogger)
        { 
            this.emailLogger = emailLogger;
        }
        public EmailSender Create(string toEmail, string subject, string body) 
        {
            return new EmailSender(toEmail, subject, body, emailLogger);
        }
    }
    private EmailSender(string toEmail, string subject,String body, ILogger emailLogger)
    {
    } 
}

Answer 1

是的 - 这很糟糕。

• 当您可以让框架完成工作时，为什么要编写所有这些代码？所有 IoC.Resolve() 调用都是多余的，你不应该写下来。

• 另一个更重要的方面，是你的组件绑定(bind)到您的服务定位器。

  您现在无法实例化它们就像那样 - 你需要一个完全设置服务定位器每次需要使用时放置组件。

• 最后但最重要的是 - 您的 SL 代码是遍布你的代码库这不是一件好事，因为当你想改变某事时，你必须在多个地方寻找。