依赖注入可选参数

Question

在使用带有构造函数注入的依赖注入框架时，使用可选参数被认为是不好的做法吗？

例：

public class ProductsController
{
    public ProductsController(IProductService productService = null, IBackOrderService = null)
    {
    }
}

我已将这两个参数指定为可选参数，但我的DI框架将始终注入两个依赖项。如果我向我的控制器添加一个需要新依赖项的新操作，那么使新的依赖项可选是不是很糟糕？即使现有的测试不需要新的依赖，我也可能打破几十个单元测试。

编辑 人们似乎对我的问题感到困惑。我永远不会在我的Web应用程序中手动构建ProductsController。这由控制器工厂（自动注入依赖项）处理。

我不喜欢的是进行这样的单元测试：

[Test]
public void Test1()
{
    var controller = new ProductsController(new MockProductService(), new MockBackOrderService());
}

现在我决定向我的控制器添加一个新的动作方法。此新操作需要新的依赖项，但现有操作都不需要。现在我必须返回并修改100个不同的单元测试，因为我添加了一个新参数。我可以通过使参数可选来避免这种情况，但我想知道这是不是一个坏主意。我的直觉不是，因为它唯一影响的是单元测试。

Answer 1

我不认为这是个好主意。构造函数注入意味着需要依赖项。如果其中一个参数为null，您甚至应该添加引发的保护线。

我认为问题在于您的单元测试。例如，我只有一个地方创建了控制器，并且模拟了支持对象（controllerContext，HttpContext，Request，Response等）。然后，如果我在构造函数中添加一个新参数，我必须在单元测试中的一个位置更改它。

也许您应该考虑在单元测试中编写通用基类，或者为测试使用“setup”例程。

Answer 2

考虑使用The Test Data Builder pattern。

在最简单的形式中，它可以作为静态测试助手方法完成

public ProductsController BuildControllerWIthMockDependencies ()
{
    var controller = new ProductsController(new MockProductService(), new MockBackOrderService());
return controller;
}

你可以使用AutoFixture as a generic Test Data Builder。

在Test Data Builders: an alternative to the Object Mother pattern中可以找到使用Test Data Builders的其他技术

Answer 3

我完全同意所有案例的接受答案，因为定义依赖性意味着实施不会有效。

但是，如果你有一些不一定需要依赖但你希望能够配置一些东西，如果已加载该依赖项。好...？这听起来有点奇怪，但它是一个有效的元编程用例 - 你认为工厂模式可能会有所帮助......但即使是工厂也可能需要一些，没有或所有依赖，因此工厂无法解决这个问题。

特征标志的真实问题。如果某项功能已关闭，则您不需要该依赖项...或者甚至无法创建它，因为没有具体的实现。所以关掉了。它编译，一切正常。但是后来有人打开了这个功能，我们突然之间就需要这种依赖。

我找到了一种方法来做到这一点 - 最好的部分是我只是通过了解另一种不太知名的依赖注入技术（我正在使用Microsoft.Extensions.DependencyInjection）来实现这一点。

为单个接口注入几个具体实现

services.AddTransient<IWarehouseRepo, ActionRepository>();
services.AddTransient<IWarehouseRepo, EventRepository>();
services.AddTransient<IWarehouseRepo, AuditRepository>();
services.AddTransient<IWarehouseRepo, ProRepository>();
services.AddTransient<IWarehouseRepo, SuperWarehouseRepository>();
services.AddTransient<IWarehouseRepo, InferiorWarehouseRepository>();
services.AddTransient<IWarehouseRepo, MonthlyStatisticsRepository>();

我最近才知道这是完全有效的，但为了这个工作，你的构造函数需要看起来像这样。

public WarehouseHandler(IEnumerable<IWarehouseRepo> repos)

所以这太酷了！我可以根据任何标准选择我需要的存储库。但这对可选依赖项有何帮助？

因为这种类型的构造函数会为您提供0个或更多依赖项。因此，如果您不添加任何依赖项，则可以使用条件语句在构造函数中分支出来

  if (repos.Count() == 0)
    return;

这是null引用安全，不需要默认值，易于调试，易于阅读和易于实现。

您现在也可以将此技术用作功能切换机制！