如何使用 Entity Framework + OData POST 多個相關實體？

Question

發布多個相關實體並檢查所需屬性的正確方法是什么？

我有兩個實體Product和Package 。 一個Product可以有多個Packages 。 沒有相關Product Package就不能存在。

當我發布具有多個Packages集合的新Product時， ModelState表示模型無效，因為Packages沒有所需的productId外鍵集。 這會導致我的 API 返回BAD REQUEST狀態。

我的理解是Entity Framework 支持這個。 我希望ModelState檢測到 Package productId FK 將自動設置，因此不會無效。

如果我刪除檢查ModelState有效性的代碼塊，實體框架會按預期運行，並且會創建Product和Packages 。

POST /api/v1/Products
BODY
{
   "name": "Coca-Cola",
   "packages": [
        {
            "count": 6,
            "quantity": 12,
            "quantityUnit": "oz"
        }
    ]
}

這是我的控制器功能：

[HttpPost]
[ODataRoute("")]
[EnableQuery]
public virtual async Task<IActionResult> PostEntity([FromBody] Product entityToCreate)
{
    //Removing this block will cause the request to succeed
    // but will also allow invalid requests to get to the database
    if (!ModelState.IsValid) 
    {
        return BadRequest(ModelState);
    }

    _context.Packages.Add(entityToCreate);
    await _context.SaveChangesAsync();

    return Created("DefaultApi", entityToCreate);
}

這是我的模型：

public class Product: ModelBase
{
    [Required]
    public string name { get; set; }

    public List<Package> packages { get; set; }
}

public class Package: ModelBase
{
    //some required props...

    [Required]
    [ForeignKey("product")]
    public Guid? productId { get; set; }
    public Product product { get; set; }
}

我調查過的一些事情：

1. 刪除packageId上的[Required]屬性並手動編輯數據庫遷移以包含約束。 這會導致數據庫稍后在堆棧中拋出錯誤。 我寧願在進入數據庫之前失敗

2. 編寫我自己的驗證屬性。 鑒於 EF 文檔聲稱支持這一點，這似乎沒有必要

3. 可能使用 OData 批量請求

Answer 1

我通常會創建一個非常具體的“模型”類（不是實體）來表示 HTTP Post（Put、Patch 等）的有效負載。 在這種情況下，您需要一組模型。 然后我有特定於這組模型的驗證規則。 有些人稱這些模型為 DTO、ViewModel 等。重要的是它們不是 EF 實體。

在驗證它們的有效性之后，您必須將這些模型映射到適當的實體中，以便它們可以通過 EF 進行持久化。 這種映射是將實體與公開模型分離的不幸稅收。 您可以手動執行此操作或使用automapper 之類的庫。

這種策略有很多優點：

• 您可以支持操作持久產品/包數據的多種變體，而不必用一組實體來適應每個變體。 這意味着您可以明智地為相同的持久化數據類型（實體）創建和公開具有不同驗證規則的不同屬性（模型）集。
• 您可以保護自己免於過度發布。 您不希望用戶能夠不受限制地設置所有屬性的狀態。
• 您公開的端點（控制器操作）具有與您的實體分離的參數。 這意味着您可以自由更改實體，而不必更改表示它們的公開模型，反之亦然。 假設您可以完全放棄 EF，轉而使用一些簡潔的 NoSQL 持久性解決方案，而無需更改您的公開 API。