【问题标题】:C# Composite key with Id in aggregate root pattern in ddd. Why?ddd 中聚合根模式中具有 Id 的 C# 复合键。为什么?
【发布时间】:2020-09-08 04:14:17
【问题描述】:

我们正在使用 ASP.NET MVC 和 EF 6.2。 我们有订单和商品,我的同事建议采用这种方法。

public class Order
{
    public int Id { get; set; }   
    public virtual ICollection<OrderItem> Items { get; set; } 
}

public class Item
{
    public int Id { get; set; }
}

public class OrderItem
{
    [Key, DatabaseGenerated(DatabaseGeneratedOption.Identity), Column(Order = 0)]        
    public int Id { get; set; }    

    [Key, Column(Order = 1)]
    public int OrderId { get; set; }
    public Order Order { get; set; 

    public int ItemId { get; set; }
    public virtual Item Item { get; set; }    

    public int Quantity { get; set; }
}

现在我们有一个复合键(Id 和 OrderId)来强制执行不变量。我不明白这一点,我认为我们可以在 OrderId (PK,FK) 和 ItemId(PK,FK) 上使用复合键来实现这一点。有人可以帮我解决这个问题吗?谢谢。

【问题讨论】:

    标签: c# asp.net-mvc entity-framework domain-driven-design aggregation


    【解决方案1】:

    这几乎是正确的。父键应该放在第一位。例如:

    [Key, Column(Order = 0)]
    public int OrderId { get; set; }
    
    [Key, DatabaseGenerated(DatabaseGeneratedOption.Identity), Column(Order = 1)]        
    public int Id { get; set; }    
    

    此设计的重点是将每个订单的 OrderItem 行存储在一起,以便存储和检索它们的成本更低,并最大限度地减少此表所需的索引数量。这种设计只需要一个聚集索引,其他方案都需要一个单独的主键和外键索引。

    【讨论】:

    • 但是Id字段是否是必要的问题不是问题吗?
    • 是的,这个问题基本上是 Id 和 OrderId 的复合键是否比 ItemId 和 OrderId 的复合键有任何优势。
    • 我假设一个订单上的多个 OrderItem 可能是同一个项目。因此,“子表”不是多对多链接表。
    猜你喜欢
    • 2020-01-22
    • 2022-03-23
    • 1970-01-01
    • 1970-01-01
    • 2016-03-21
    • 1970-01-01
    • 2022-12-16
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多