使用servicelocation而不是构造函数注入来避免编写工厂类的负载是否不好

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);
    }
}

现在的问题是，我们最终创建了整个lotta工厂类，而人们并不总是知道要使用它们（有时他们自己来创建它们）。像这样编写类的最大缺点是什么：

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

Pro：现在，我们可以安全地使用构造函数，而无需工厂类了。Con：我们必须引用Service
Locator（我不担心可测试性，它易于使用模拟容器作为容器的后备服务）。

是否有一些令人讨厌的理由说明为什么我们不应该这样做？

编辑：经过一番思考，我想通过拥有一个私有的构造函数，并嵌套Factory类，可以使实现和工厂保持在一起，并防止人们不正确地创建类，所以这个问题有些不切实际。
关于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（）调用都是多余的，您不必编写它们。
• 另一个甚至更重要的方面是您的组件与服务定位器绑定在一起。

现在，您无法像这样实例化它们-每次需要使用组件时，都需要一个完全设置好的服务定位器。

• 最后，但至少是机器人，您的SL代码会散布在整个代码库中，这不是一件好事，因为当您要更改某些内容时，必须在多个位置进行查找。