使用Func代替IoC接口

上下文：我正在使用C＃

我设计了一个类，为了隔离它并使单元测试更容易，我传入了它的所有依赖关系。它在内部没有对象实例化。但是，不是引用接口来获取所需的数据，而是让它引用通用的Funcs返回所需的数据/行为。当注入其依赖项时，我可以使用lambda表达式来实现。

对我来说，这似乎是一种更好的方法，因为在单元测试期间我不必做任何繁琐的模拟。另外，如果周围的实现有根本变化，则只需要更改工厂类即可；无需更改包含逻辑的类。

但是，我之前从未见过IoC这样做，这使我认为我可能会缺少一些潜在的陷阱。我唯一想到的是与未定义Func的C＃早期版本的轻微不兼容，在我看来，这不是问题。

使用泛型委托/高阶函数（例如Func for IoC），而不是使用更具体的接口时，是否存在任何问题？

如果一个接口仅包含一个功能，而不包含更多功能，并且没有令人信服的理由引入两个名称（接口名称和接口内部的功能名称），则使用a Func可以避免不必要的样板代码，并且在大多数情况下更可取-就像您开始设计DTO并认识到它只需要一个成员属性一样。

我猜很多人都习惯使用interfaces，因为在依赖关系注入和IoC流行时，还没有真正等同Func于Java或C ++中的类的人（我什至不确定Func当时C＃是否可用）。 ）。因此interface，尽管使用起来Func会更优雅，但许多教程，示例或教科书仍然更喜欢这种形式。

您可能会看看我以前关于接口隔离原则和Ralf Westphal的Flow Design方法的答案。由于您自己（和其他一些人）已经提到过的完全相同的原因，此范式仅使用Func参数实现DI 。因此，正如您所看到的，您的想法并不是一个真正的新想法，相反。

是的，我自己将这种方法用于生产代码，用于需要以流水线形式处理数据的程序，其中包括几个中间步骤，包括每个步骤的单元测试。因此，我可以给您第一手的经验，它可以很好地工作。

我发现IoC的主要优点之一是，它将允许我通过命名它们的接口来命名我的所有依赖项，并且容器将通过匹配类型名称来知道向构造函数提供哪个依赖项。这很方便，并且比允许使用更多描述性的依赖项名称Func<string, string>。

我还经常发现，即使只有一个简单的依赖关系，有时也需要具有多个功能-接口允许您以自记录的方式将这些功能组合在一起，而不是拥有多个都像Func<string, string>，Func<string, int>。

肯定有很多时候，简单地将一个委托作为依赖来传递很有用。这是关于何时使用委托与拥有很少成员的接口的判断。除非真的很清楚该参数的目的是什么，否则我通常会在生成自文档代码方面犯错。即。编写界面。

使用泛型委托/高阶函数（例如Func for IoC），而不是使用更具体的接口时，是否存在任何问题？

并不是的。Func是它自己的一种接口（英文含义，不是C＃含义）。“此参数是在询问时提供X的东西。” Func甚至具有仅根据需要延迟提供信息的好处。我对此做了一些建议，建议适度进行。

至于缺点：

• IoC容器通常会做一些魔术来以级联的方式连接依赖项，并且在某些事物存在T并且某些事物存在时可能不会发挥很好的作用Func<T>。
• Funcs具有某种间接性，因此进行推理和调试可能会更加困难。
• Funcs延迟实例化，这意味着运行时错误可能在奇怪的时间出现，或者在测试期间根本不出现。它还可能增加操作顺序问题的机会，并且根据您的使用，初始化顺序中会出现死锁。
• 您传递给Func的内容可能是封闭的，带有一些开销和复杂性。
• 调用Func比直接访问对象要慢一些。（不足以使您在任何非平凡的程序中都注意到它，但是它在那里）

让我们举一个简单的例子-也许您正在注入一种记录方式。

注入课程

class Worker: IWorker
{
    ILogger _logger;

    Worker(ILogger logger)
    {
        _logger = logger;
    }
    void SomeMethod()
    {
        _logger.Debug("This is a debug log statement.");
    }
}        

我认为这很清楚。而且，如果您使用的是IoC容器，则无需显式注入任何东西，只需将其添加到合成根目录中：

container.RegisterType<ILogger, ConcreteLogger>();
container.RegisterType<IWorker, Worker>();
....
var worker = container.Resolve<IWorker>();

调试时Worker，开发人员只需要查阅组合根目录即可确定正在使用的具体类。

如果开发人员需要更复杂的逻辑，则可以使用整个界面：

    void SomeMethod()
    { 
       if (_logger.IsDebugEnabled) {
           _logger.Debug("This is a debug log statement.");
       }
    }

注入方法

class Worker
{
    Action<string> _methodThatLogs;

    Worker(Action<string> methodThatLogs)
    {
        _methodThatLogs = methodThatLogs;
    }
    void SomeMethod()
    {
        _methodThatLogs("This is a logging statement");
    }
}        

首先，请注意，构造函数参数的名称现在更长methodThatLogs。这是必要的，因为您无法确定an Action<string>应该做什么。使用该接口，它是完全清楚的，但是在这里，我们必须依靠参数命名。这似乎天生就不太可靠，并且在构建期间很难执行。

现在，我们如何注入这种方法？好吧，IoC容器不会为您做这件事。因此，您在实例化时将其明确注入Worker。这带来了两个问题：

1. 实例化一个更多的工作 Worker
2. 尝试进行调试的开发人员Worker会发现，很难弄清楚具体实例被调用了。他们不能仅仅参考合成词根。他们将不得不跟踪代码。

如果我们需要更复杂的逻辑怎么办？您的技术仅公开一种方法。现在，我想您可以将复杂的内容烘焙到lambda中：

var worker = new Worker((s) => { if (log.IsDebugEnabled) log.Debug(s) } );

但是在编写单元测试时，如何测试该lambda表达式？它是匿名的，因此您的单元测试框架无法直接实例化它。也许您可以找出一些聪明的方法来做到这一点，但是它可能比使用接口更大的PITA。

差异摘要：

1. 仅注入方法会使推断目标变得更加困难，而接口则清楚地传达了目标。
2. 仅注入方法会使接收注入的类的功能较少。即使您今天不需要，明天也可能需要。
3. 您不能仅使用IoC容器自动注入方法。
4. 您无法从组合根目录中判断在特定实例中哪个具体的类在起作用。
5. 对lambda表达式本身进行单元测试是一个问题。

如果您对上述所有方法都满意，则可以只注入该方法。否则，我建议您坚持传统并注入一个界面。

考虑一下我很久以前写的以下代码：

public interface IPhysicalPathMapper
{
    /// <summary>
    /// Gets the physical path represented by the relative URL.
    /// </summary>
    /// <param name="relativeURL"></param>
    /// <returns></returns>
    String GetPhysicalPath(String relativeURL);
}

public class EmailBuilder : IEmailBuilder
{
    public IPhysicalPathMapper PhysicalPathMapper { get; set; }
    public ITextFileLoader TextFileLoader { get; set; }
    public IEmailTemplateParser EmailTemplateParser { get; set; }
    public IEmaiBodyRenderer EmailBodyRenderer { get; set; }

    public String FromAddress { get; set; }

    public MailMessage BuildMailMessage(String templateRelativeURL, Object model, IEnumerable<String> toAddresses)
    {
        String templateText = this.TextFileLoader.LoadTextFromFile(this.PhysicalPathMapper.GetPhysicalPath(templateRelativeURL));

        EmailTemplate template = this.EmailTemplateParser.Parse(templateText);

        MailMessage email = new MailMessage()
        {
            From = new MailAddress(this.FromAddress),
            Subject = template.Subject,
            IsBodyHtml = true,
            Body = this.EmailBodyRenderer.RenderBodyToHtml(template.BodyTemplate, model)
        };

        foreach (MailAddress recipient in toAddresses.Select<String, MailAddress>(toAddress => new MailAddress(toAddress)))
        {
            email.To.Add(recipient);
        }

        return email;
    }
}

它需要相对于模板文件的相对位置，将其加载到内存中，呈现消息正文，并组装电子邮件对象。

您可能会IPhysicalPathMapper想到，“只有一个功能。可能是一个Func。” 但是实际上，这里的问题是IPhysicalPathMapper甚至不应该存在。更好的解决方案是仅将路径参数化：

public class EmailBuilder : IEmailBuilder
{
    public ITextFileLoader TextFileLoader { get; set; }
    public IEmailTemplateParser EmailTemplateParser { get; set; }
    public IEmaiBodyRenderer EmailBodyRenderer { get; set; }

    public String FromAddress { get; set; }

    public MailMessage BuildMailMessage(String templatePath, Object model, IEnumerable<String> toAddresses)
    {
        String templateText = this.TextFileLoader.LoadTextFromFile(templatePath);

        EmailTemplate template = this.EmailTemplateParser.Parse(templateText);

        MailMessage email = new MailMessage()
        {
            From = new MailAddress(this.FromAddress),
            Subject = template.Subject,
            IsBodyHtml = true,
            Body = this.EmailBodyRenderer.RenderBodyToHtml(template.BodyTemplate, model)
        };

        foreach (MailAddress recipient in toAddresses.Select<String, MailAddress>(toAddress => new MailAddress(toAddress)))
        {
            email.To.Add(recipient);
        }

        return email;
    }
}

这就提出了许多其他问题来改进此代码。例如，也许它应该只接受一个EmailTemplate，然后它应该接受一个预渲染的模板，然后也许应该对其进行内联。

这就是为什么我不喜欢将控制反转作为一种普遍的模式。通常，它是构成所有代码的类神解决方案。但是实际上，如果您普遍使用它（而不是很少使用），那么它会鼓励您引入很多完全向后使用的不必要的接口，从而使您的代码变得更加糟糕。（从某种意义上来说，调用者应该真正负责评估那些依赖关系并传递结果，而不是由类本身调用调用。）

应该谨慎使用接口，并且还应该谨慎使用控制反转和依赖注入。如果您有大量的代码，您的代码将变得更加难以解密。