.NET Core处理PostgreSQL外键不存在类数据库异常的最佳实践

处理这类PostgreSQL外键约束抛出的数据库异常，通常有两种主流方案，你可以根据业务的性能要求、可维护性要求选择：

方案1：保存前预校验（提前查询Client是否存在） #

• 适用场景：绝大多数普通业务场景，对错误提示精细化要求高，后续有其他关联逻辑依赖Client存在的场景
• 实现方式：在业务逻辑层执行保存操作前，先调用主键查询判断Client是否存在，示例代码：

  var clientExists = await _context.Clients.AnyAsync(c => c.Id == dto.ClientId);
  if (!clientExists)
  {
      throw new CustomNotFoundException($"id为{dto.ClientId}的客户端不存在");
  }
  

  全局异常处理器捕获自定义的CustomNotFoundException后，直接返回对应的友好提示即可。
• 优缺点：
  • 优势：代码可读性、可维护性高，和数据库实现解耦，后续更换数据库不需要调整逻辑
  • 劣势：多一次主键查询，不过主键单表查询性能极高，在99%的业务场景下这点性能损耗完全可以忽略。如果你的业务逻辑本身就需要查询Client的其他字段做其他校验，那这次查询还可以复用，不存在额外开销。

方案2：全局异常中解析PostgreSQL原生异常 #

• 适用场景：接口QPS极高、对性能要求极致，不愿意接受额外查询开销的场景
• 实现方式：PostgreSQL违反外键约束的异常有固定的错误码23503，你可以在全局异常处理器中捕获Npgsql.PostgresException，判断SqlState等于23503时，解析异常信息中的约束名和非法值，拼接友好提示。
  你需要提前在EF Core配置中给外键设置明确的命名，比如FK_你的表名_Clients_ClientId，这样解析时可以直接匹配到是ClientId字段的外键错误，再提取异常信息中的非法值，就能生成你需要的友好提示。
• 优缺点：
  • 优势：没有额外的数据库查询，性能最优
  • 劣势：和PostgreSQL强绑定，更换数据库需要重写解析逻辑；异常解析规则需要随着新增外键同步维护，维护成本更高。

注意事项 #

就算采用预校验方案，也要在全局异常中兜底处理外键约束异常，避免极端并发场景（预校验完成后、保存数据前，对应的Client被删除）下，直接返回原始数据库错误给前端。

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