在ASP.NET Core 2的Identity Server中添加非Identity表是否需独立DbContext？

好问题！在ASP.NET Core 2的Identity Server里处理非Identity业务表，不是必须要使用单独的DbContext，具体要不要拆分，得看你的项目复杂度、业务耦合度和架构规划，下面给你分两种场景说明：

场景1：共用同一个DbContext（推荐小型/耦合度高的项目） #

• 如果你要加的非Identity表和Identity认证授权逻辑关联紧密，或者项目规模不大，完全可以把这些表的实体放到你已经用于Identity的DbContext中（也就是继承自IdentityDbContext<ApplicationUser, IdentityRole<long>, long>的那个上下文）。
• 操作很简单：直接在这个DbContext里添加public DbSet<YourNonIdentityEntity> YourNonIdentityEntities { get; set; }，后续执行迁移时，这些表会和Identity相关的表（比如AspNetUsers、AspNetRoles）一起生成到数据库中。
• 优势：不用额外处理多上下文的事务一致性问题，开发和维护成本低，适合快速迭代的小型项目。

场景2：使用独立的DbContext（推荐大型/模块化项目） #

• 如果你的非Identity业务和Identity认证逻辑完全独立，或者项目需要做模块化拆分（比如把用户中心和业务系统分开），那单独创建一个DbContext来管理这些非Identity表会更合理。
• 注意事项：如果业务中涉及到跨两个上下文的事务操作，你需要通过IDbContextTransaction或者依赖注入提供的事务服务来保证数据的一致性。
• 优势：职责划分清晰，每个DbContext只专注于一块业务，便于后期的维护、扩展和单元测试，适合大型分布式或模块化架构的项目。

结合你已经扩展的ApplicationUser类，给个小示例参考：

// 共用DbContext的情况
public class AppDbContext : IdentityDbContext<ApplicationUser, IdentityRole<long>, long>
{
    public AppDbContext(DbContextOptions<AppDbContext> options) : base(options)
    {
    }

    // 添加你的非Identity表DbSet
    public DbSet<Order> Orders { get; set; }
}

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