依赖注入可选参数

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

例子：

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个不同的单元测试，因为我添加了一个新参数。我可以通过使参数可选来避免这种情况，但我想知道这是不是一个好主意。我的直觉认为不，因为它影响的唯一的事情是单元测试。

来源

2012-04-20 Dismissile

找到如何'ProductsController'没有它的依赖关系运作？ – Matthew 2012-04-20 20:34:34

@Mthethew ProductsController的某些部分将在没有任何依赖性的情况下运行。显然，DI容器将始终注入所有的依赖关系。 – Dismissile 2012-04-20 20:35:26

我从来没有手动实例化我的控制器，除了在我的单元测试中。这就是为什么我想知道如果让参数成为可选项，它甚至是重要的。默认情况下，参数将始终注入（在我的单元测试之外）。 – Dismissile 2012-04-20 20:37:08

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

我认为问题出在你的单元测试上。例如，我只有一个地方创建控制器并支持对象被模拟（controllerContext，HttpContext，Request，Response等）。然后，如果我在构造函数中添加一个新参数，我必须在单元测试中只在一个地方进行更改。也许你应该考虑在你的单元测试中编写一个通用的基类，或者为测试使用“设置”例程。

来源

2012-04-20 20:56:14

这就是我正在寻找的东西。我可能确实需要重构我的单元测试，只做一个地方的设置。现在我一直在努力。感谢您的输入。 – Dismissile 2012-04-20 20:58:32

考虑使用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

来源

2013-07-30 10:29:05

依赖注入可选参数

回答

相关问题