从电商系统实战看C#继承在ASP.NET Core中的高阶应用
当我们在Visual Studio中新建一个ASP.NET Core Web API项目时，那些自动生成的Controller基类和DbContext基类已经暗示了继承在这个框架中的核心地位。但很多开发者对继承的理解仍停留在"动物->猫狗"的教科书示例层面，这就像拿着瑞士军刀却只用它开瓶盖。
1. 电商系统中的继承架构设计
在真实的电商系统开发中，继承不是语法练习题，而是解决以下痛点的利器：
- 重复代码：每个实体类都需要ID、创建时间等基础字段
- 统一行为：所有订单都需要状态验证逻辑
- 标准化响应：API返回格式需要全局一致性
- 审计追踪：谁在什么时候修改了什么数据
假设我们正在构建一个跨境电商平台，产品模型的核心继承结构可以这样设计：
public abstract class AuditableEntity { public int Id { get; set; } public DateTime CreatedAt { get; set; } public string CreatedBy { get; set; } public DateTime? ModifiedAt { get; set; } public string ModifiedBy { get; set; } public virtual void UpdateAuditFields(string userId) { ModifiedAt = DateTime.UtcNow; ModifiedBy = userId; } } public class Product : AuditableEntity { public string Sku { get; set; } public decimal Price { get; set; } // 其他产品特有属性 } public class InventoryItem : AuditableEntity { public int ProductId { get; set; } public int StockQuantity { get; set; } // 库存特有属性 }这种设计带来了几个实际优势：
- 自动审计追踪：所有实体自动获得修改记录能力
- 统一标识：不用在每个类中重复定义Id字段
- 简化仓储层：基础CRUD操作可以抽象到泛型仓储
2. EF Core中的继承映射策略实战
当这些继承的模型遇到Entity Framework Core时，我们有三种主要的映射策略选择：
| 策略类型 | 存储方式 | 适用场景 | 性能特点 |
|---|---|---|---|
| TPH (Table Per Hierarchy) | 单表存储所有类型 | 子类差异小 | 查询最快，但可能产生稀疏列 |
| TPT (Table Per Type) | 每个类型单独表 | 子类差异大 | 需要JOIN操作，写入较慢 |
| TPC (Table Per Concrete) | 只存具体类型表 | 明确类型边界 | 无继承关系查询优势 |
对于我们的电商系统，TPH可能是最佳选择：
protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.Entity<AuditableEntity>() .HasDiscriminator<string>("EntityType") .HasValue<Product>("Product") .HasValue<InventoryItem>("Inventory"); // 其他配置... }实际项目中还需要考虑：
- 鉴别器列的索引优化
- 批量操作时的性能影响
- 导航属性的特殊处理
3. 服务层中的行为继承模式
继承在服务层的应用往往比数据层更有价值。比如支付处理服务：
public abstract class PaymentServiceBase { protected readonly ILogger _logger; public PaymentServiceBase(ILogger logger) { _logger = logger; } public abstract Task<PaymentResult> ProcessAsync(PaymentRequest request); protected virtual bool ValidateRequest(PaymentRequest request) { // 基础验证逻辑 if(request.Amount <= 0) { _logger.LogWarning("无效的支付金额"); return false; } return true; } } public class CreditCardPaymentService : PaymentServiceBase { public CreditCardPaymentService(ILogger<CreditCardPaymentService> logger) : base(logger) { } public override async Task<PaymentResult> ProcessAsync(PaymentRequest request) { if(!ValidateRequest(request)) return PaymentResult.Failed("验证失败"); // 信用卡特定处理逻辑 } }这种设计模式带来了：
- 日志等横切关注点的统一处理
- 验证逻辑的可复用性
- 模板方法模式的天然支持
4. Controller层的继承技巧
在ASP.NET Core中，Controller继承可以解决很多重复劳动：
[ApiController] [Route("api/[controller]")] public abstract class ApiControllerBase : ControllerBase { protected IMediator Mediator => HttpContext.RequestServices.GetService<IMediator>(); protected ActionResult<T> HandleResult<T>(Result<T> result) { if (result.IsSuccess) return Ok(result.Value); return BadRequest(result.Error); } } [Authorize(Roles = "Admin")] public class ProductsController : ApiControllerBase { [HttpGet] public async Task<ActionResult<List<ProductDto>>> GetProducts() { var result = await Mediator.Send(new GetProductsQuery()); return HandleResult(result); } }这种基类Controller提供了：
- 统一响应处理：所有API返回相同格式
- 依赖解析：简化服务获取
- 全局特性：如认证授权配置
5. 继承的替代方案与权衡
虽然继承强大，但在某些场景下组合可能更合适：
// 使用组合代替继承的例子 public class ProductService { private readonly IAuditTrail _auditTrail; private readonly IStockValidator _validator; public ProductService(IAuditTrail auditTrail, IStockValidator validator) { _auditTrail = auditTrail; _validator = validator; } public void UpdateProduct(Product product) { if(_validator.Validate(product)) { // 业务逻辑 _auditTrail.RecordUpdate(product); } } }何时选择组合而非继承：
- 当行为可能动态变化时
- 需要模拟多重继承时
- 不同维度关注点混合时
在最近的一个库存系统重构中，我们将原本深层次的继承结构改为了组合模式，使得系统更灵活应对业务变化。但要注意，过度使用组合也会导致服务膨胀问题。
