ASP.NET Core DI容器中注入记录是否可行？

Question

记录可以让我的代码更简洁。例如，不用写这样的代码：

public class OrderService
{
  private readonly EcommerceContext _context;

  public OrderService(EcommerceContext context)
  {
    _context = context;
  }
}

我只是有

public record OrderService(EcommerceContext Context)

所以，我的问题是，将记录注入DI容器中是否可以，或者是否有任何缺点？

- John

---

一个订单服务听起来不应该首先是一条记录。你在这个订单服务中使用了哪些记录的特性？ - mason

它可以让我的代码更简洁。类没有主构造函数。 - John

Answer 1

记录是一个具有自动生成构造函数的类；DI容器不区分它们两者之间的差异。

个人认为，记录类型是消除实践DI和松耦合所需的基础设施代码/垃圾的好方法。私有字段、构造函数和私有字段赋值只是允许我们的代码松耦合所需的样板代码。记录类型允许将此代码减少到最低限度，这非常棒。

记录类型唯一的缺点是，在当前版本的C#中，没有办法防止传入的依赖项为null。对我来说，在大多数情况下，这并不是什么大问题，这种情况下我喜欢使用记录类型。如果空值检查是强制性的（例如因为您正在编写可重用库，例如通过NuGet发布的内容），则需要回退到手动实现构造函数的老式类。

在撰写我们的DI书籍时，Mark Seemann和我实际上讨论了使用记录类型作为构造函数注入的主要演示。然而，我们决定不在书中使用记录类型，主要有以下三个原因：

• 在出版时，尚未推出包含记录类型的C# 9。
• 失去进行前置条件检查的能力对于本书的示例来说是一个绝佳的交易破坏者，因为我们不想假定使用DI容器来组合实例；我们还描述了一种称为Pure DI的实践。在Pure DI中，没有工具可以保证不将null值注入构造函数。
• 我们希望这本书也适用于其他面向对象编程语言的开发人员阅读。尽管记录类型在未来几年内将在C#社区中非常普遍，但对于许多其他面向对象编程语言来说可能并非如此。

也许在（假设的）第三版书籍中，我们会改变主意。当C#的未来版本允许记录类型构造函数自动检查（和防止）空参数时，这可能特别发生。

- Steven