.net - 使用依赖注入(inject)，我发现自己创建了工厂来进行单元测试。这是正常的吗？

Question

检查以下简化的示例代码:

public class RequestManager
{
    public RequestManager()
    {

    }

    public void ProcessRequest(byte[] data)
    {
        IRequest request = new Request(data);
        request.Send();
    }
}

当我发现自己可以使用这段代码来测试它时，我以:

public class RequestManager
{
    private IRequestFactory requestFactory;

    public RequestManager(IRequestFactory requestFactory)
    {
        this.requestFactory = requestFactory;
    }

    public void ProcessRequest(byte[] data)
    {
        IRequest request = this.requestFactory.CreateRequest(data);
        request.Send();
    }
}

CreateRequest 方法只有新的 Request(data)，所以我可以模拟工厂并返回一个模拟。

问题是我开始有很多工厂来处理如此简单的任务，我想知道这是否正常，或者是否有一种模式或其他方法可以帮助我克服这个问题。

有什么想法吗？提前致谢。

Answer 1

这不仅是正常的，而且是体面设计的标志。在正确应用 DI 的应用程序中，您不需要工厂:

• 从依赖注入(inject)容器解析的对象
• POCO/DTO(因为它们是简单的值(value)存储)
• 在大多数情况下，.NET BCL 对象(尽管这可能会有所不同)

对于其他一切，工厂是一个不错的选择。为什么？

• 它提供了统一的对象创建方式(这样整个团队都知道当你需要IRequest实例时，你应该注入(inject)IRequestFactory)
• 它不会引发任何不必要的问题(例如“我应该在创建后设置 SomeProperty 吗？” 或 “我使用哪个构造函数？。Factory.CreateInstance()简单而直观——无需解释任何东西，所有的决定都已经做出并嵌入在工厂本身中)
• 结合模拟，它大大简化了单元测试(尤其是当无法轻易使用假数据创建实际对象时)

撇开单元测试不谈，当您在 3、6、12 个月后返回您的代码时，前两点具有极大的好处 - 工厂减轻开发人员对事物的决策这不需要首先做出任何决定。

不用担心要使用哪个构造函数和要传递什么参数，您有一个非常简单的契约(Contract)可以回答所有可能的问题，作为开发人员，您可以专注于实际问题。