asp.net core 内置依赖注入长代码答案

【问题标题】：asp.net core build-in dependency injection long codeasp.net core 内置依赖注入长代码
【发布时间】：2016-12-22 12:16:51
【问题描述】：

在我们之前的应用程序中，我们使用了 StructureMap，我们可以编写非常少的代码。

在每个服务之前，我们添加了如下依赖项：

[SetterProperty]
public IXService XService { get; set; }

在构造函数中

ObjectFactory.BuildUp(this);

然后在测试中我们可以简单地实例化它

var service = new XService();

现在，我们启动另一个应用程序并使用 asp.net 核心内置 DI 容器。看起来我们应该为每个测试编写大量代码和非常长的构造函数：

    private readonly ILogger<AccountsController> _logger;
    private readonly IMapper _mapper;
    private readonly IAccountBlService _accountBlService;
    private readonly IValidationHelper _validationHelper;
    private readonly IValidator<AccountDTO> _accountDTOValidator;
    private readonly Example _example;
    private readonly IConfiguration _configuration;

    public AccountsController(BillingContext context, ILogger<AccountsController> logger, IMapper mapper, IAccountBlService accountBlService, 
        IValidationHelper validationHelper, IValidator<AccountDTO> accountDTOValidator, IOptions<Example> example, IConfiguration configuration)
    {
        _logger = logger;
        _mapper = mapper;
        _accountBlService = accountBlService;
        _validationHelper = validationHelper;
        _accountDTOValidator = accountDTOValidator;
        _configuration = configuration;
        _example = example.Value;
    }

我们没有找到更短的方法吗？是在不久的将来计划的吗？我们应该使用 StructureMap 代替内置容器吗？还是有缺点？谢谢！

【问题讨论】：

标签： dependency-injection asp.net-core ioc-container structuremap

【解决方案1】：

我们没有找到更短的方法吗？ 简而言之：不，不是默认容器。但我建议您阅读 Mark Seemann 的 .NET 中的依赖注入（如果您有，请忽略我的说法），因为您听说过“组合根”吗？恕我直言，您声明依赖项的方式具有相同数量的代码，只是分散在您的代码库中。虽然您应该将其真正保存在一个地方以实现可维护性。
是否计划在不久的将来使用？我不知道，但实际上如果你看一下，它的代码量是一样的，只是集中式的。然而，我们使用 NServiceBus 在 BusConfiguration 上调用“RegisterComponents”的能力，它使用反射在一次调用中注册所有依赖项。你可以寻找可以做同样事情的容器。现在，如果您正在考虑您的测试，如果您使用 XUnit，您可以通过测试类的构造函数设置您的 SUT。在工厂类中重构它，因此您只需编写一次。通过这种方式，您还可以加入 mock 以保持测试干净。
我们应该使用 StructureMap 代替内置容器吗？ 如果你希望。我们使用 Autofac。
或者这样做有缺点吗？ 到目前为止，我们还没有遇到过。有时您需要 IServiceProvider 来获得特殊的“技巧”，但总有办法。

注意：如果您担心控制器中有 7 个依赖项（确实很多），有几个选项：

查看依赖的范围。如果它仅用于 1 或 2 个操作方法中，您还可以在操作方法的签名中声明它 [FromService]
您的控制器是否做得太多？留意上帝的课程。也许它需要重构。毕竟，控制器只不过是动作方法的逻辑集合。
可以合并依赖关系吗？有时它们似乎需要分开，但在大多数情况下，它们总是成对出现。看起来有很高的内聚性，您可以将它们组合在一个辅助类中以保持内聚性。

【讨论】：