CQRS场景下：FluentValidation与Handler的数据库验证最佳实践

先理清验证的边界 #

首先得明确：验证分两类，职责边界要划清：

• 无状态输入验证：比如字段格式、必填性、长度限制这类不依赖外部数据的，完全适合放在FluentValidation里，在请求到达Handler前就拦截，快速过滤无效请求。
• 状态依赖验证：像你遇到的“文档ID是否已关联实体”这种需要查询数据库状态的，就得谨慎处理，因为涉及业务逻辑和并发风险。

两种实现方式的优劣分析 #

1. 在Handler中处理唯一验证 #

• 优势：
  • 职责清晰：Command Handler本来就负责编排整个业务流程，把“检查唯一性”和“执行插入”放在一起，符合CQRS的设计原则——Handler处理命令的完整生命周期。
  • 避免验证类越界：FluentValidation的定位是做输入校验，注入数据库依赖会让它承担业务逻辑，违背单一职责，后续维护起来会越来越乱。
  • 天然兼容并发兜底：就算前置查询通过了，插入时遇到并发写入触发数据库约束，Handler里可以直接捕获异常并转化为友好错误（虽然你想减少，但这步不能省）。
• 劣势：
  • 请求会走到Handler层才被拦截，多了一点微小的服务开销，但实际场景下几乎可以忽略。

2. 在FluentValidation中注入依赖做验证 #

• 优势：
  • 更早拦截无效请求，不会进入后续业务流程，节省一点资源。
• 劣势：
  • 破坏验证类的单一职责：把需要查询数据库的逻辑塞进验证类，会让它从“输入校验器”变成“业务逻辑处理器”，测试和维护成本都会上升。
  • 并发问题无解：就算验证通过，插入时还是可能因为并发写入触发约束异常，最后还是要在Handler或全局层面处理，等于做了重复校验。
  • 测试变复杂：验证类现在依赖数据库仓储，单元测试需要模拟仓储或搭建测试数据库，增加了测试的复杂度。

推荐的落地方式 #

1. 拆分验证逻辑：
   • 把文档ID的格式、非空这类无状态校验，放在FluentValidation里，提前拦截无效输入。
   • 把“文档是否已关联实体”的状态校验，放在Command Handler里：先查询数据库，存在就直接返回业务错误；不存在再执行插入操作。
2. 保留数据库异常兜底：
   不管做了多少前置校验，都要在Handler或全局异常处理器里捕获数据库的约束违反异常，转化为用户友好的错误提示——并发场景下，前置查询无法100%避免冲突，数据库约束是最后一道防线。
3. 可选优化：全局异常统一处理：
   可以把数据库约束异常的捕获逻辑抽成全局中间件或过滤器，不用在每个Handler里重复写，减少代码冗余。

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