从ASP.NET Identity基础用户继承还是为不同角色实现各自接口？

首先给出结论：优先选择单User类实现对应角色接口的方案，不推荐使用继承方案，具体原因和适用场景如下：

接口实现方案的优势 #

• 符合接口隔离与组合优于继承的设计原则
  两类用户属性完全一致，差异仅在可执行的操作，用接口标记不同角色的行为边界，既不会破坏用户类的属性内聚性，也不会产生多余的类层级。如果使用继承方案，你需要额外定义Buyer、Seller两个子类，大部分编程语言不支持类的多继承，当后续出现同时具备买家、卖家身份的用户时，继承方案完全无法适配，而接口实现方案可以直接通过class User implements IBuyer, ISeller的写法兼容这类场景。
• 扩展性更高
  后续如果新增其他用户角色（比如平台管理员、分销员），只需要新增对应角色接口即可，不需要调整现有类的继承结构，也不会产生大量仅行为有差异的冗余子类。

示例代码参考（TypeScript） #

// 买家接口：定义买家可执行的操作
interface IBuyer {
  submitOrder(): void;
  applyAfterSales(): void;
}

// 卖家接口：定义卖家可执行的操作
interface ISeller {
  publishCommodity(): void;
  confirmDelivery(): void;
}

// 通用用户类：实现对应角色接口即可拥有对应能力
class User implements IBuyer, ISeller {
  // 两类用户通用的属性
  userId: number;
  username: string;
  contactInfo: string;

  // 实现IBuyer接口的方法
  submitOrder() {
    // 下单业务逻辑
  }
  applyAfterSales() {
    // 售后申请业务逻辑
  }

  // 实现ISeller接口的方法
  publishCommodity() {
    // 商品发布业务逻辑
  }
  confirmDelivery() {
    // 确认发货业务逻辑
  }
}

继承方案的适用边界 #

如果你的业务场景满足以下所有条件，也可以选择继承方案：

1. 两类用户后续完全不会新增差异化的属性
2. 业务逻辑上永远不会出现同时拥有两种角色的用户
3. 两类用户的操作逻辑完全独立，没有交叉复用的需求

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