从EF Core ChangeTracker移除特定条目：方案可行性咨询

问题背景 #

在.NET 7/EF Core 7环境中，存在无法控制的数据库变更跟踪黑盒流程，仅能掌控变更保存方法。需要在保存操作中排除非Schedule和Vacation两张核心表的条目，当前采用移除ChangeTracker对应条目的方案是否合理？有无更通用的实现方式？数据库规模较小，单表记录均少于10k。

当前实现代码 #

// 只提交Schedule和Vacation的变更，先筛选出不属于这两类的实体条目
var unDbSets = context.ChangeTracker.Entries()
    .Where(e => e.Entity is not Schedule && e.Entity is not Vacation)
    .Where(p => p.State == EntityState.Added || p.State == EntityState.Deleted || p.State == EntityState.Modified)
    .ToList();

foreach (var unDbSet in unDbSets)
{
    if (unDbSet.State == EntityState.Added)
    {
        // 新增实体从未入库，直接分离，EF就不会跟踪它，也不会提交变更
        // 注：最初尝试设为Unchanged会抛出异常
        unDbSet.State = EntityState.Detached;
    }
    else
    {
        // 已入库的实体，将状态改为Unchanged，EF就不会对它执行任何操作，数据库保持原状态
        unDbSet.State = EntityState.Unchanged;
    }
}

// 最终保存跟踪到的变更
context.SaveChanges();

当前方案的合理性 #

这个方案在当前场景下完全可行，原因如下：

• 数据库规模小，遍历ChangeTracker的性能开销可以忽略不计；
• 逻辑精准：针对新增实体直接分离（避免EF尝试插入），已存在实体重置为Unchanged（取消变更提交），完美达到只提交两张核心表变更的需求；
• 规避了EF Core的状态切换限制：新增实体没有原始快照，无法直接设为Unchanged，改用分离的处理方式完全符合EF的规则。

但方案也有局限：

• 硬编码实体类型，后续新增需要保留的表时，必须手动修改筛选逻辑；
• 仅通过实体类型判断，若存在实体继承关系，需要额外调整判断逻辑。

更通用的实现方式 #

1. 特性标记法（推荐） #

通过自定义特性标记允许保存的实体，后续新增只需给实体加特性，无需修改保存逻辑：

步骤1：定义特性

[AttributeUsage(AttributeTargets.Class)]
public class AllowSaveAttribute : Attribute
{
}

步骤2：标记允许保存的实体

[AllowSave]
public class Schedule { /* 实体定义 */ }

[AllowSave]
public class Vacation { /* 实体定义 */ }

步骤3：修改筛选逻辑

// 从EF模型中获取所有标记了AllowSave特性的实体类型
var allowedTypes = context.Model.GetEntityTypes()
    .Where(t => t.ClrType.GetCustomAttribute<AllowSaveAttribute>() != null)
    .Select(t => t.ClrType)
    .ToList();

// 筛选出需要排除的实体条目
var entriesToExclude = context.ChangeTracker.Entries()
    .Where(e => !allowedTypes.Contains(e.Entity.GetType()))
    .Where(p => p.State is EntityState.Added or EntityState.Deleted or EntityState.Modified)
    .ToList();

// 处理状态（逻辑同原代码）
foreach (var entry in entriesToExclude)
{
    entry.State = entry.State == EntityState.Added 
        ? EntityState.Detached 
        : EntityState.Unchanged;
}

context.SaveChanges();

2. 配置驱动法（高扩展性） #

把允许保存的实体类型放到配置文件中，通过反射加载，完全解耦代码与实体列表：

步骤1：添加配置到appsettings.json

{
  "AllowedSaveEntities": ["YourNamespace.Schedule", "YourNamespace.Vacation"]
}

步骤2：读取配置并筛选

// 从配置中读取允许保存的实体类型名称
var allowedTypeNames = Configuration.GetSection("AllowedSaveEntities").Get<string[]>();
// 转换为Type对象
var allowedTypes = allowedTypeNames.Select(Type.GetType).ToList();

// 后续筛选和状态处理逻辑同特性标记法
var entriesToExclude = context.ChangeTracker.Entries()
    .Where(e => !allowedTypes.Contains(e.Entity.GetType()))
    .Where(p => p.State is EntityState.Added or EntityState.Deleted or EntityState.Modified)
    .ToList();

foreach (var entry in entriesToExclude)
{
    entry.State = entry.State == EntityState.Added 
        ? EntityState.Detached 
        : EntityState.Unchanged;
}

context.SaveChanges();

3. 扩展方法封装法（高复用性） #

把逻辑封装成DbContext扩展方法，调用时只需指定允许保存的实体类型：

public static class DbContextExtensions
{
    // 重载：指定两个实体类型
    public static int SaveChangesOnlyFor<T1, T2>(this DbContext context)
    {
        return context.SaveChangesOnlyFor(typeof(T1), typeof(T2));
    }

    // 重载：支持任意数量的实体类型
    public static int SaveChangesOnlyFor(this DbContext context, params Type[] allowedTypes)
    {
        var entriesToExclude = context.ChangeTracker.Entries()
            .Where(e => !allowedTypes.Contains(e.Entity.GetType()))
            .Where(p => p.State is EntityState.Added or EntityState.Deleted or EntityState.Modified)
            .ToList();

        foreach (var entry in entriesToExclude)
        {
            entry.State = entry.State == EntityState.Added 
                ? EntityState.Detached 
                : EntityState.Unchanged;
        }

        return context.SaveChanges();
    }
}

调用示例：

// 保存Schedule和Vacation的变更
context.SaveChangesOnlyFor<Schedule, Vacation>();

// 若后续需要新增允许保存的表，直接添加类型即可
context.SaveChangesOnlyFor<Schedule, Vacation, NewEntity>();

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