FastEndpoints 中实现验证器本地化的最佳实践

理解问题背景

在使用 FastEndpoints 框架时，开发者经常会遇到验证错误消息本地化的问题。默认情况下，FastEndpoints 将验证器注册为单例模式，这种设计虽然提高了性能，但也带来了本地化方面的挑战。

核心问题分析

当开发者尝试通过中间件设置请求文化时，发现验证错误消息无法正确本地化。这是因为：

1. 验证器作为单例被缓存
2. 文化信息通常在请求级别设置
3. 单例验证器无法感知每个请求的文化变化

解决方案详解

FastEndpoints 提供了优雅的解决方案，开发者可以在验证规则中使用 IStringLocalizer 来实现本地化：

sealed class MyValidator : Validator<MyRequest>
{
    public MyValidator()
    {
        RuleFor(x => x.Name)
            .Length(5)
            .WithMessage(_ => Resolve<IStringLocalizer<MyValidator>>()["invalid_name"]);
    }
}

关键点说明：

1. 使用 Resolve<IStringLocalizer<T>>() 获取本地化服务
2. 必须使用委托形式 (_ =>) 传递消息，避免被 FluentValidation 缓存
3. 保持验证器为单例模式，不影响性能

性能考量

FastEndpoints 坚持使用单例验证器是经过深思熟虑的设计决策：

1. 每个请求实例化验证器会显著影响性能
2. 本地化服务本身是轻量级的
3. 通过委托方式延迟获取本地化字符串，既保持性能又实现本地化

进阶建议

对于模块化架构的项目，推荐使用以下方式管理验证器：

1. 利用 FastEndpoints 的类型发现机制
2. 避免手动注册验证器到 DI 容器
3. 通过配置指定包含验证器的程序集

bld.Services.AddFastEndpoints(o => 
    o.Assemblies = [typeof(SomeAssembly).Assembly]);

总结

FastEndpoints 通过巧妙的设计，在保持高性能的同时支持验证消息本地化。开发者应遵循框架推荐的方式，使用 IStringLocalizer 配合委托语法来实现多语言支持，而不是尝试改变验证器的生命周期。这种方案既保证了系统性能，又满足了国际化需求，是 FastEndpoints 框架中处理本地化验证消息的最佳实践。