EF Core 中自引用拥有类型的设计陷阱与解决方案

问题背景

在EF Core 9.0.0版本中，开发者在设计实体模型时遇到一个特殊场景：当一个实体类型(User)拥有多个相同类型的子实体(UserTimestamp)时，如果这些子实体又包含导航属性回指父实体，会导致模型构建失败。这种自引用结构在审计跟踪场景中很常见，比如记录实体的创建和更新时间以及操作用户。

典型场景分析

考虑以下典型业务需求：

• 需要为系统中的实体记录创建和更新时间
• 同时需要记录执行这些操作的用户
• 这些审计信息需要作为实体的一部分进行持久化

开发者通常会设计一个UserTimestamp值对象，包含用户ID、用户导航属性和时间戳，然后将其作为拥有类型嵌入到业务实体中。对于普通实体这工作良好，但当这个模式应用于User实体自身时就会出现问题。

技术细节解析

正常工作情况

当User实体只拥有一个UserTimestamp时，EF Core能正确构建模型：

1. 自动生成OwnerUserId影子属性作为外键
2. 正确处理UserTimestamp中的UserId到User的导航
3. 形成完整的双向关联关系

问题重现条件

当User实体拥有两个UserTimestamp属性(Created和Updated)时，EF Core在模型构建阶段会抛出异常"对象'UserTimestamp'已从模型中移除"。这是因为：

1. EF Core尝试为两个拥有类型实例建立相同的元数据结构
2. 在处理第二个拥有类型时，模型构建器内部状态出现不一致
3. 自引用关系导致类型解析出现循环依赖

解决方案比较

临时解决方案

1. 类型复制法：创建两个不同的类型(CreateTimestamp和UpdateTimestamp)，虽然结构相同但名义类型不同

   • 优点：简单直接
   • 缺点：造成代码重复，维护成本高

2. 单属性法：只使用一个UserTimestamp属性

   • 优点：完全避免问题
   • 缺点：不能满足业务需求

推荐解决方案

等待EF Core团队修复此问题后，可以采用以下标准模式：

public class User
{
    public int Id { get; set; }
    public UserTimestamp Created { get; set; }
    public UserTimestamp Updated { get; set; }
}

[Owned]
public class UserTimestamp
{
    [ForeignKey(nameof(User))]
    public int UserId { get; set; }
    public User User { get; set; }
    public DateTime Timestamp { get; set; }
}

// 配置
modelBuilder.Entity<User>().OwnsOne(u => u.Created, o => o.WithOwner().HasForeignKey("OwnerUserId"));
modelBuilder.Entity<User>().OwnsOne(u => u.Updated, o => o.WithOwner().HasForeignKey("OwnerUserId"));

设计建议

1. 对于审计字段这种通用模式，考虑使用拦截器或影子属性实现
2. 在必须使用拥有类型的情况下，暂时采用类型复制方案
3. 关注EF Core的更新，此问题已被标记为将在未来版本修复
4. 复杂模型构建时，考虑分步配置和验证

总结

EF Core中拥有类型的自引用设计是一个强大但需要谨慎使用的特性。在需要同一类型被多次拥有的场景下，开发者需要特别注意模型构建的配置方式。理解EF Core内部处理拥有类型的机制，可以帮助开发者设计出既满足业务需求又稳定的数据模型。