在ASP.NET Core DI容器中注入一條記錄是否可以？

Question

記錄使我的代碼更短。 例如，而不是

public class OrderService
{
  private readonly EcommerceContext _context;

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

我只有

public record OrderService(EcommerceContext Context)

所以，我的問題是，在 DI 容器中注入一條記錄是否可以，或者它有什么缺點嗎？

Answer 1

一條記錄只是一個帶有自動生成的構造函數的 class； DI 容器不區分它們兩者。

就我個人而言，我發現記錄類型是一種消除實踐 DI 和松散耦合所需的基礎結構代碼/垃圾的好方法。 私有字段、構造函數和私有字段分配只是允許我們的代碼松散耦合所需的樣板代碼。 記錄允許將此代碼減少到最低限度，這很棒。

記錄類型的唯一缺點是，對於 C# 的當前版本，無法防止傳入的依賴項成為null 。 對我來說，在大多數情況下這沒什么大不了的，在這種情況下我喜歡使用記錄類型。 如果 null 檢查是強制性的（例如因為您正在編寫一個可重用的庫，例如您通過 NuGet 發送的東西），您需要回退到使用手動實現的構造函數的老式類。

在撰寫有關 DI 的書時，Mark Seemann 和我實際上討論了使用記錄類型作為我們書中構造函數注入的主要演示。 然而，我們決定不在我們的書中使用記錄類型，主要出於三個原因：

• 在發布時，包含記錄類型的 C# 9 尚不可用
• 喪失進行前提條件檢查的能力是本書示例的一大障礙，因為我們不想假設 DI 容器用於組合實例； 還有一種稱為Pure DI的實踐，我們在本書中對其進行了廣泛描述。 使用 Pure DI，沒有工具可以保證不將null值注入構造函數。
• 我們希望這本書對於使用其他 OOP 語言的開發人員來說也是可讀的。 盡管記錄類型將在幾年內在 C# 社區中非常普遍，但對於許多其他 OOP 語言來說情況可能並非如此。

也許我們會在本書的（假設的）第三版中改變主意。 當 C# 的未來版本允許記錄類型構造函數自動檢查（並阻止）null arguments 時，尤其可能會發生這種情況。