应用依赖注入时如何最小化代码量？

Question

这让我很烦很长时间。许多 c# 特性都是关于减少代码和冗余的。但是我们有依赖注入。而这个功能需要我们指定我们想要的东西 3 次

public class MyClass
{
    private readonly ServiceType _service; // first

    public MyClass(ServiceType service) // second
    {
        _service = service; // third
    }
}

现在假设您需要注入 10 个服务。玩得开心滚动。

现在我们已经有了通过公共属性初始化一个类的好模式，我们甚至可以拥有仅初始化属性，所以这种模式变得越来越像构造函数。但据我所知，依赖注入当然不支持这一点......

你知道有什么框架会使用它吗？有什么理由说明它还不是 .NET Core MVC 中的默认 DI 模式？

public class MyClass
{
    public ServiceType SomeService {get; set; }
}

var property = new MyClass { SomeService = new ServiceType() };

没那么难。只是需要一点反思。

Answer 1

如果我的理解正确，您想知道在应用依赖注入时是否有办法（在 C# 中）最大限度地减少您的类中所需的代码量（管道）。我相信最近的 C# 版本确实提供了这方面的解决方案，而不必回退到代码异味和反模式。

我想做一个重要的说明，即如果您“需要注入 10 个服务”，您正在应用构造函数过度注入代码气味。有许多可用的设计模式和重构可以帮助您避免创建具有超过四个或五个依赖项的类。我将在这里详细讨论有关构造函数过度注入的问题和解决方案。相反，我想参考我的书的第 6.1 节，Dependency Injection Principles, Practices, and Patterns。不过，我的经验是，有四个或五个依赖项，由 DI 引起的“垃圾”数量是可行的。

您建议使用Property Injection 作为解决方案，以最大程度地减少启用松散耦合造成的麻烦。然而，属性注入会导致 temporal coupling 设计异味，即使在仅 init 属性的情况下也是如此。除此之外，Constructor Over-Injection 的根本问题是类有太多的依赖关系；它可能违反了Single-Responsibility Principle。使用属性注入并没有改变这一事实。因此，不建议使用属性注入而不是构造函数注入。

相反，C# 9 引入了Record types 的概念，它提供了一种减少杂乱无章的卓越方法，而无需求助于诸如时间耦合之类的代码气味。使用 C# 9 的记录类型语法，您的 MyClass 示例可以简化为以下内容：

public record MyClass(ServiceType service)
{

}

如果MyClass 有五个依赖项，它可能如下所示：

public record MyClass(
    IOrderRepository repository,
    IMessageService messageService,
    IBillingSystem billingSystem,
    ILocationService locationService,
    IInventoryManagement inventoryManagement)    
{
}

记录类型在其定义中包含其依赖项，C# 编译器将自动为您的依赖项和分配生成（除其他外）构造函数、（公共）成员。这意味着如果没有所需的依赖项（这是构造函数注入的一个重要特性），仍然无法创建类型。

最重要的缺点 (IMO) 是缺少前置条件检查，例如空值检查。可以将null 值注入MyClass（通过调用new MyClass(null)，这在手动实现构造函数时可能会被阻止。然而，对我来说，这是一个很小的代价，特别是如果你使用防止null被注入的DI容器。未来版本的C#可能会克服这个缺点，因为它允许基于简写语法生成空检查。不幸的是，这个功能在过去被延迟了好几次。它是不清楚何时将此功能添加到语言中。