Entity Framework中关联实体修改时自动更新父实体修改时间

方案一：扩展审计模型+变更追踪检测导航属性 #

先定义包含基础审计字段的接口：

public interface IAuditableModel
{
    DateTime Created { get; set; }
    DateTime Modified { get; set; }
}

// 实现接口的Recipe实体
public class Recipe : IAuditableModel
{
    public int Id { get; set; }
    public string Name { get; set; }
    public DateTime Created { get; set; }
    public DateTime Modified { get; set; }
    public ICollection<Step> Steps { get; set; } = new List<Step>();
}

public class Step
{
    public int Id { get; set; }
    public string Description { get; set; }
    public int RecipeId { get; set; }
    public Recipe Recipe { get; set; }
}

重写DbContext的保存方法，同时检测自身变更与关联子实体的状态：

public override int SaveChanges()
{
    TrackAuditableEntities();
    return base.SaveChanges();
}

public override async Task<int> SaveChangesAsync(CancellationToken cancellationToken = default)
{
    TrackAuditableEntities();
    return await base.SaveChangesAsync(cancellationToken);
}

private void TrackAuditableEntities()
{
    var now = DateTime.UtcNow;
    // 处理新增实体的创建/修改时间
    foreach (var entry in ChangeTracker.Entries<IAuditableModel>()
        .Where(e => e.State == EntityState.Added))
    {
        entry.Entity.Created = now;
        entry.Entity.Modified = now;
    }

    // 处理自身变更的实体的修改时间
    foreach (var entry in ChangeTracker.Entries<IAuditableModel>()
        .Where(e => e.State == EntityState.Modified))
    {
        entry.Entity.Modified = now;
    }

    // 检查Recipe关联的Steps是否有变更，更新Recipe的修改时间
    foreach (var recipeEntry in ChangeTracker.Entries<Recipe>())
    {
        var hasStepChanges = recipeEntry.Collection(r => r.Steps).CurrentValue
            .Any(s => ChangeTracker.Entries<Step>().FirstOrDefault(e => e.Entity.Id == s.Id)?.State is EntityState.Added or EntityState.Modified or EntityState.Deleted);
        
        if (hasStepChanges && recipeEntry.State != EntityState.Modified)
        {
            recipeEntry.Entity.Modified = now;
            recipeEntry.Property(r => r.Modified).IsModified = true;
        }
    }
}

这个方案把审计逻辑集中在DbContext层，通过EF变更追踪器直接检测子实体状态，无需侵入业务代码。

方案二：将Step配置为Recipe的拥有实体（Owned Entity） #

既然Step只能通过Recipe修改，可将其设为拥有实体，EF会将Step的变更视为Recipe的一部分，简化审计逻辑：

public class Recipe : IAuditableModel
{
    public int Id { get; set; }
    public string Name { get; set; }
    public DateTime Created { get; set; }
    public DateTime Modified { get; set; }
    public List<Step> Steps { get; set; } = new List<Step>();
}

// Step作为拥有实体，无需独立Id（EF自动生成复合主键）
public class Step
{
    public string Description { get; set; }
    public int Order { get; set; }
}

// 在DbContext中配置拥有实体
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Recipe>()
        .OwnsMany(r => r.Steps, s =>
        {
            s.WithOwner().HasForeignKey("RecipeId");
            s.Property<int>("Id");
            s.HasKey("Id");
        });
}

配置后，任何Step的新增、修改、删除都会触发Recipe的变更标记，此时审计逻辑只需处理IAuditableModel的变更即可，且拥有实体完全支持EF迁移，后续修改Step结构时能正常生成数据库变更脚本。

方案三：领域事件驱动更新 #

若倾向领域驱动设计，可通过领域事件解耦修改时间更新逻辑：

// 定义领域事件
public class StepChangedEvent : INotification
{
    public Recipe Recipe { get; }
    public StepChangedEvent(Recipe recipe) => Recipe = recipe;
}

// Step实体中触发事件
public class Step
{
    public int Id { get; set; }
    public string Description { get; set; }
    public int RecipeId { get; set; }
    public Recipe Recipe { get; set; }

    public void UpdateDescription(string newDescription)
    {
        Description = newDescription;
        DomainEvents.Raise(new StepChangedEvent(Recipe));
    }
}

// 事件处理器
public class StepChangedEventHandler : INotificationHandler<StepChangedEvent>
{
    public Task Handle(StepChangedEvent notification, CancellationToken cancellationToken)
    {
        notification.Recipe.Modified = DateTime.UtcNow;
        return Task.CompletedTask;
    }
}

// 在保存前处理领域事件
private void ProcessDomainEvents()
{
    var domainEvents = ChangeTracker.Entries<IHasDomainEvents>()
        .SelectMany(e => e.Entity.DomainEvents)
        .ToList();

    foreach (var domainEvent in domainEvents)
    {
        _mediator.Publish(domainEvent).Wait();
    }
}

// 在审计逻辑前调用事件处理
private void TrackAuditableEntities()
{
    ProcessDomainEvents();
    // 原有审计逻辑...
}

该方案将业务逻辑与审计逻辑解耦，符合单一职责原则，适合复杂领域场景。

不推荐序列化方案的原因 #

将Step序列化为Recipe的JSON字段（如StepsJson）存在明显弊端：

• 后续修改Step结构时，EF迁移无法识别JSON内部的结构变化，需手动处理数据迁移；
• 无法对Step的单个字段进行查询、过滤或索引，查询灵活性大幅降低；
• 序列化/反序列化会带来额外性能开销，易引发版本兼容问题。

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