Entity Framework 对 ID 键的情有独钟：为什么复合键会很麻烦

Source: Dev.to

为什么 Entity Framework 要求主键

Entity Framework 基于一个基本原则：每个实体必须能够唯一标识。这不是随意的规则——它对 EF 的更改跟踪、关系管理和数据库操作至关重要。

没有主键，EF 无法：

• 跟踪哪些实体已被修改
• 管理实体之间的关系
• 生成正确的 UPDATE 或 DELETE 语句
• 维护 identity‑map 模式（确保内存中同一键的实体只有一个实例）

基于约定的方法

EF 使用约定让你的工作更轻松。默认情况下，它会查找名为：

• Id
• Id

public class Product
{
    public int Id { get; set; }          // EF 自动将其识别为主键
    public string Name { get; set; }
    public decimal Price { get; set; }
}

这种基于约定的方法意味着在绝大多数情况下 零配置。它简洁、直观且可预测。

当单键不足时：复合键的出现

有时你的领域模型需要复合键——由多个列组成的主键。经典例子包括：

• 订单行项目 – 通过 OrderId 和 LineNumber 两者标识
• 多对多关联表 – 使用双方的外键
• 遗留数据库 – 已经存在复合键的情况
• 自然键 – 如 CountryCode + StateCode

public class OrderLineItem
{
    public int OrderId { get; set; }
    public int LineNumber { get; set; }
    public string ProductName { get; set; }
    public int Quantity { get; set; }
}

这看起来相当无害，对吧？但事情就在这里变得复杂了。

Source: …

在 Entity Framework 中复合键的复杂性

1. 没有约定支持

与单列键不同，EF 不能通过约定自动检测复合键。必须显式配置它们：

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity()
        .HasKey(o => new { o.OrderId, o.LineNumber });
}

2. 导航属性的挑战

当关系涉及复合键时，配置会变得冗长且容易出错：

public class Order
{
    public int OrderId { get; set; }
    public List<LineItem> LineItems { get; set; }
}

public class OrderLineItem
{
    public int OrderId { get; set; }
    public int LineNumber { get; set; }
    public Order Order { get; set; }
}

// 需要的配置:
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity()
        .HasKey(o => new { o.OrderId, o.LineNumber });

    modelBuilder.Entity()
        .HasOne(o => o.Order)
        .WithMany(o => o.LineItems)
        .HasForeignKey(o => o.OrderId);
}

3. 查找实体变得繁琐

使用单键时，查找实体很简单：

var product = await context.Products.FindAsync(42);

使用复合键时，必须按正确顺序提供所有键值：

var lineItem = await context.OrderLineItems.FindAsync(orderId, lineNumber);

顺序错误会导致混乱的结果或异常。

4. 标识问题与更改跟踪

EF 的更改跟踪器使用主键来标识实体。使用复合键时，重复的键值会导致失败：

var item1 = new OrderLineItem { OrderId = 1, LineNumber = 1, ProductName = "Widget" };
var item2 = new OrderLineItem { OrderId = 1, LineNumber = 1, ProductName = "Gadget" };

context.OrderLineItems.Add(item1);
context.OrderLineItems.Add(item2);

await context.SaveChangesAsync();   // 异常！两者拥有相同的复合键

5. 多对多关系变得混乱

EF Core 5+ 引入了自动多对多关系，但它们在简单的连接表上表现最佳。添加复合键或额外属性会迫使显式配置：

public class StudentCourse
{
    public int StudentId { get; set; }
    public int CourseId { get; set; }
    public DateTime EnrollmentDate { get; set; }
    public string Grade { get; set; }

    public Student Student { get; set; }
    public Course Course { get; set; }
}

// 显式配置:
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity()
        .HasKey(sc => new { sc.StudentId, sc.CourseId });

    modelBuilder.Entity()
        .HasOne(sc => sc.Student)
        .WithMany(s => s.StudentCourses)
        .HasForeignKey(sc => sc.StudentId);

    modelBuilder.Entity()
        .HasOne(sc => sc.Course)
        .WithMany(c => c.StudentCourses)
        .HasForeignKey(sc => sc.CourseId);
}

6. 迁移与数据库演进

在初始创建后更改复合键非常痛苦：

• 需要删除并重新创建外键约束
• 必须重新构建索引
• 数据迁移脚本变得复杂
• 回滚场景困难

7. 性能考虑

复合键会增大索引和外键列的大小，导致：

• 索引页更大 → 更多 I/O
• 尤其在大表上，连接操作更慢
• 更改跟踪器的内存消耗更高

要点

Entity Framework 对 单一主键 的强烈偏好源于简洁性、性能和可靠的更改跟踪。虽然支持复合键，但它们会引入大量样板配置，增加 bug 风险，并可能使迁移和性能调优变得复杂。

在设计新模型时，考虑是否可以引入 代理键 (Id) 来让 EF 正常工作，将复合键保留给真正不可避免的遗留场景。

性能影响

• 更大的索引大小（尤其是宽复合键）
• 更复杂的查询计划
• 更慢的 JOIN 操作

外键索引会复制数据

-- Single key index: 4 bytes (INT)
-- Composite key index with (INT, INT, GUID): 4 + 4 + 16 = 24 bytes
-- Multiply by millions of rows...

真实世界的恐怖案例

下面是一个展示其复杂性的示例：

public class TimeSheetEntry
{
    public int EmployeeId { get; set; }
    public DateTime Date { get; set; }
    public int ProjectId { get; set; }
    public int TaskId { get; set; }
    public decimal Hours { get; set; }
}

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    // 四列复合键！
    modelBuilder.Entity()
        .HasKey(t => new { t.EmployeeId, t.Date, t.ProjectId, t.TaskId });

    // 现在想象一下为 Employee、Project 和 Task 添加关系...
    // 并尝试高效地查询它们...
    // 以及向初级开发者解释为什么 Find() 需要四个参数...
}

Source: …

更佳方案：代理键

大多数开发者——以及 Microsoft 的官方指南——都建议使用代理键（自增整数或 GUID），即使存在自然复合键：

public class OrderLineItem
{
    public int Id { get; set; }               // Surrogate key
    public int OrderId { get; set; }
    public int LineNumber { get; set; }
    public string ProductName { get; set; }
    public int Quantity { get; set; }

    public Order Order { get; set; }
}

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    // Enforce uniqueness with a unique index instead
    modelBuilder.Entity()
        .HasIndex(o => new { o.OrderId, o.LineNumber })
        .IsUnique();
}

好处

• 在所有实体中使用简单、一致的主键
• 关系配置更容易
• Find() 操作直接且高效
• 在大多数情况下性能更佳
• 可以在不破坏关系的前提下更改自然键

当复合键有意义时

尽管复杂，复合键有时是正确的选择：

• 遗留数据库集成，无法更改模式
• 纯连接表，在多对多关系中没有额外数据
• 极高性能场景，代理键的开销会产生影响
• 领域建模，复合键真正代表实体的身份

Conclusion

Entity Framework 对单列 ID 键的偏好并非随意决定的——它源自数十年的 ORM 经验和实用的软件工程实践。复合键在 EF 中确实可以使用，但会给你的代码、配置以及思维模型带来显著的复杂性。

在考虑使用复合键之前，先问自己：

• 这真的是实体的自然标识吗，还是仅仅一个唯一约束？
• 这种复杂性在六个月后仍然值得吗？
• 我能否通过使用代理键（surrogate key）并加上唯一索引来实现同样的目标？

在大多数情况下，答案是坚持使用简单的 Id 属性，并通过唯一索引来强制自然键约束。你的未来的自己（以及你的团队成员）会感谢你的选择。

你在 Entity Framework 中使用复合键的经验是什么？有没有发现哪些模式可以让它们更易于管理？欢迎在评论中分享你的想法！