基于EF Core的实体变更管理求助：关联属性场景解决方案

针对你用EF Core拦截器实现变更管理时遇到的导航属性（尤其是集合型）处理难题，以下是几种落地性较强的同类实现方案和思路：

方案1：拆分变更记录，关联主/子实体变更 #

不要只序列化主实体的JSON，而是为每个发生变更的实体（包括主实体、导航属性关联的实体）单独生成变更记录：

• 在OnSavingChangesAsync中，遍历ChangeTracker里所有状态为Added/Modified/Deleted的实体，不管是主实体还是关联实体
• 每个变更记录存实体类型、主键、原始值快照、当前值快照、变更类型，并通过ChangeRequestId关联到同一个变更请求
• 把所有变更实体标记为Detached，只持久化变更请求和关联的子变更记录
• 审批通过时，逐个处理子变更记录：
  • 新增实体：反序列化当前值，添加到DbContext并设为Added状态
  • 修改实体：先从数据库拉取最新实例，用当前值覆盖后设为Modified状态
  • 删除实体：从数据库找到对应实体，设为Deleted状态
• 集合导航属性的增减会自动拆分为子实体的变更记录，EF Core会通过外键自动维护关联关系

方案2：基于EF Core EntityEntry的完整状态序列化 #

直接利用EF Core的EntityEntry来捕获所有变更细节：

• 在拦截器中遍历ChangeTracker.Entries()，对每个变更的EntityEntry，序列化其OriginalValues、CurrentValues、EntityState和实体类型
• 集合导航属性的变更本质是集合内实体的增删改，同样会被ChangeTracker追踪到对应的EntityEntry，无需单独处理集合本身
• 审批时，反序列化每个EntityEntry信息：
  • 创建对应类型的实体实例，用PropertyValues.SetValues()方法分别赋值原始值和当前值
  • 根据记录的EntityState设置实体在DbContext中的状态
  • 确保反序列化后的实体包含正确的外键值，EF Core会自动处理关联

方案3：领域事件驱动的变更捕获（DDD友好） #

跳出EF Core变更追踪的局限，从业务层面记录变更意图：

• 在领域模型中给属性修改、集合操作（如添加/移除子实体）添加领域事件，比如CustomerOrderAdded、OrderItemUpdated
• 用户操作领域模型时自动触发这些事件，将事件信息（操作类型、实体标识、变更内容）收集到变更请求中
• 变更请求不再存实体完整值，而是存领域事件集合
• 审批通过时，重放这些领域事件到领域模型，再将模型状态持久化到数据库
• 这种方式能清晰记录业务变更意图，避免依赖EF Core的技术细节，更贴合DDD架构

关键注意点 #

• 并发控制：审批时要对比变更记录中的原始值与数据库当前值，或者用乐观锁版本号，防止覆盖他人修改
• 序列化避坑：EF Core代理类序列化时要排除代理属性，可通过context.Entry(entity).CurrentValues.ToObject()获取无代理的实体对象
• 集合移除的区分：要明确集合中实体的移除是“解除关联”还是“删除实体本身”，前者只需修改外键，后者要生成删除类型的变更记录

内容的提问来源于stack exchange，提问作者Mihaimyh