ASP.NET Core MVC中在IValidatableObject的Validate方法修改模型属性是否合理？

首先明确：不推荐在IValidatableObject.Validate方法里修改模型属性。原因很简单——Validate方法的核心职责是验证数据合法性，而非修改数据。这么做会违反单一职责原则，时间久了会让代码逻辑混乱：其他开发者看代码时会困惑为什么验证逻辑里还偷偷改了数据；如果验证失败，修改后的属性返回给前端，还可能让用户搞不清自己输入的内容为啥变了。

下面是几种更合适的方案，按推荐程度排序：

1. 全局模型绑定器（最推荐，适合批量处理） #

在模型绑定阶段就完成数据清理，这是ASP.NET Core处理请求数据的标准流程，能确保后续所有环节（包括验证）拿到的都是干净的数据。

比如要全局处理所有字符串属性的首尾空格，可以自定义模型绑定器和绑定器提供者：

首先实现绑定器：

public class TrimStringModelBinder : IModelBinder
{
    public Task BindModelAsync(ModelBindingContext bindingContext)
    {
        var valueResult = bindingContext.ValueProvider.GetValue(bindingContext.ModelName);
        if (valueResult != ValueProviderResult.None)
        {
            bindingContext.ModelState.SetModelValue(bindingContext.ModelName, valueResult);
            var rawValue = valueResult.FirstValue;
            if (!string.IsNullOrEmpty(rawValue))
            {
                bindingContext.Result = ModelBindingResult.Success(rawValue.Trim());
                return Task.CompletedTask;
            }
        }
        bindingContext.Result = ModelBindingResult.Success(null);
        return Task.CompletedTask;
    }
}

然后实现绑定器提供者：

public class TrimStringModelBinderProvider : IModelBinderProvider
{
    public IModelBinder GetBinder(ModelBinderProviderContext context)
    {
        if (context.Metadata.ModelType == typeof(string))
        {
            return new TrimStringModelBinder();
        }
        return null;
    }
}

最后在Program.cs里注册：

builder.Services.AddControllersWithViews(options =>
{
    // 插入到最前面，确保优先使用我们的绑定器
    options.ModelBinderProviders.Insert(0, new TrimStringModelBinderProvider());
});

这样所有字符串类型的请求参数都会自动被去掉首尾空格，无需在每个模型里重复写逻辑。

2. 属性Setter中处理（适合少量属性的场景） #

如果只有个别属性需要清理，可以直接在模型的属性Setter里处理：

private string _username;
public string Username
{
    get => _username;
    set => _username = value?.Trim();
}

这种方式简单直接，缺点是如果有大量属性需要处理，会产生重复代码。

3. 自定义属性特性（灵活度高） #

可以创建一个自定义特性，标记需要清理的属性，然后配合模型绑定器处理，这样能更精准地控制哪些属性需要清理：

[AttributeUsage(AttributeTargets.Property)]
public class TrimAttribute : Attribute
{
}

修改之前的模型绑定器，只处理带有[Trim]特性的字符串属性即可。

4. DTO转换时处理（适合分层架构） #

如果项目采用了分层架构，有专门的请求DTO和业务模型，可以在DTO转换为业务模型的环节做数据清理。比如用AutoMapper的自定义映射规则：

CreateMap<RequestDto, BusinessModel>()
    .ForMember(dest => dest.Name, opt => opt.MapFrom(src => src.Name?.Trim()));

这种方式能保持请求DTO的原始性，同时让业务模型拿到干净的数据。

内容的提问来源于stack exchange，提问作者Jesper Jensen