无包装对象时使用FluentValidation验证对象列表的最佳方法

FluentValidation 官方提供的集合验证示例默认针对对象内部嵌套集合的场景，针对根级直接传入的List<T>/IEnumerable<T>类型（常见于普通业务方法批量校验、ASP.NET Core 控制器直接接收集合入参两类场景），你列出的三种方案都能实现效果，但各有局限，也存在更轻量化的原生实现路径。

现有三种方案的优劣势分析 #

• 为IEnumerable<Person>创建专属验证器
  逻辑符合FluentValidation的原生开发范式，但默认配置下ASP.NET Core的自动验证管线不会自动识别根集合类型对应的验证器，需要额外编写模型绑定适配代码才能让ModelState自动触发校验，为每个集合类型单独写验证器也会产生重复代码。
• 遍历集合逐次调用单元素验证器
  实现最直观、可控，适合业务逻辑中的手动验证场景，但无法接入ASP.NET Core自动验证流程，每个接收集合入参的接口都要重复编写遍历、结果拼接逻辑，手动处理带索引的错误提示也容易出错。
• 为集合包裹父对象后编写父类验证器
  可以完美兼容自动验证流程，但属于侵入式修改，会改变原有方法/接口的参数契约，比如前端原本直接传对象数组，包裹后需要改成传带集合属性的包装对象，非必要不推荐。

更推荐的实现方式 #

通用泛型集合验证器（覆盖两类场景） #

不需要为每个集合类型单独写验证器，只需要实现一个泛型版本的集合验证器，复用单元素的验证逻辑：

public class EnumerableValidator<TElement> : AbstractValidator<IEnumerable<TElement>>
{
    public EnumerableValidator(IValidator<TElement> elementValidator)
    {
        // 校验集合本身的规则可以按需添加，比如要求集合非空、数量上限
        RuleFor(x => x).NotEmpty();
        RuleFor(x => x.Count).LessThanOrEqualTo(100).WithMessage("单次提交最多100条数据");
        // 逐元素校验，复用单元素验证器
        RuleForEach(x => x).SetValidator(elementValidator);
    }
}

• 普通业务场景使用：直接从DI容器获取/实例化对应泛型验证器，调用Validate方法即可拿到全量校验结果，错误信息会自动携带元素索引，不需要手动遍历拼接。
• ASP.NET Core自动验证场景：在注册FluentValidation时，将泛型验证器注册为开放泛型，补充简单的模型验证提供器适配后，所有接收集合类型入参的接口都会自动触发对应校验，ModelState会自动填充对应索引位置的错误信息，和单个模型、嵌套集合的验证体验完全一致，不需要修改接口参数结构，也不需要在接口内写手动校验逻辑。

轻量手动验证场景 #

如果只是临时在业务逻辑中做一次集合校验，不需要接入自动验证，完全可以直接用FluentValidation内置的批量验证能力，不需要单独编写集合验证器：

var personValidator = new PersonValidator();
var result = personValidator.Validate(persons, options => 
{
    options.IncludeAllRuleSets();
    // 按需追加集合级别的校验规则
    options.RuleFor(x => x).NotEmpty();
});

方案选择建议 #

• 临时手动校验：优先选择直接调用单元素验证器做批量验证，或者简单遍历校验，不需要额外封装。
• 项目内存在大量集合校验/需要接入ASP.NET Core自动验证：优先用泛型集合验证器方案，一次配置全局复用，无侵入性。
• 只有当接口本身就需要传递额外参数（比如操作人信息、分页参数）时，再选择包裹父对象的方案，不要单纯为了验证修改参数结构。

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