在ABP框架中使用EF Core的Table Per Hierarchy(TPH)相关问题咨询

我在多个ABP项目中实际使用过TPH方案处理多类型实体（包括多类型订单、多类型通知等场景），以下是实际遇到的问题和注意事项：

常见问题 #

1. 实体映射配置问题 #

你需要手动在你的DbContext类的OnModelCreating方法中显式配置鉴别器列，不能依赖ABP的默认自动映射：

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    base.OnModelCreating(modelBuilder);
    
    // 配置订单TPH映射
    modelBuilder.Entity<Order>()
        .HasDiscriminator<string>("OrderType") // 鉴别器列名可自定义
        .HasValue<EnvelopeOrder>("EnvelopeOrder")
        .HasValue<CopyJobOrder>("CopyJobOrder");
}

如果派生实体有独有的属性，这些属性必须设置为可空类型，否则EF Core迁移时会报错，因为同一张表中其他类型的订单不需要填充这些字段。

2. 仓储使用问题 #

ABP默认支持通过基类仓储IRepository<Order>查询所有类型的订单，查询结果会自动映射为对应的派生实体类型，你可以直接用LINQ的OfType<T>()方法筛选指定类型的订单：

var envelopeOrders = await _orderRepository.GetQueryableAsync()
    .OfType<EnvelopeOrder>()
    .ToListAsync();

如果你需要直接使用派生实体的泛型仓储IRepository<EnvelopeOrder>，需要先在DbContext中添加对应的DbSet属性：

public DbSet<EnvelopeOrder> EnvelopeOrders { get; set; }
public DbSet<CopyJobOrder> CopyJobOrders { get; set; }

3. 不同订单类型的编辑逻辑处理 #

ABP本身没有提供自动适配派生实体编辑逻辑的功能，确实需要你自行判断订单类型：

• 如果是前后端分离架构：后端通用查询接口返回订单数据时带上鉴别器OrderType的值，前端根据OrderType的值渲染对应类型的编辑表单，提交时请求对应类型的保存接口即可
• 如果是服务端渲染的MVC/Razor Pages项目：在通用编辑Action中查询到订单实例后，判断实体类型，再重定向到对应派生类型的编辑页面，或者动态渲染对应类型的分部视图即可

其他需要注意的事项 #

• 不要随意修改已上线的鉴别器取值，也不要随意删除已经在用的派生实体类型，否则会导致已有数据无法正确映射为实体，触发运行时异常
• ABP的审计日志、多租户、扩展属性、软删除等内置功能对派生实体完全生效，不需要额外配置
• 如果后续某个派生实体的独有字段越来越多，会导致整张订单表的冗余字段过多，查询性能下降，这种场景可以后续切换为TPT（表 per 类型）模式，ABP对TPT的支持和原生EF Core完全一致，但是数据迁移成本较高
• 做批量更新、删除操作时，一定要先按鉴别器过滤对应类型的订单，避免误修改其他类型的订单数据

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