ASP.NET Core分层应用中验证逻辑的合理放置方案问询

我完全理解你的困扰——既要利用.NET Core内置的表单验证能力，又要把复杂业务验证放在服务层，还要遵循DRY原则，确实需要一个平衡的方案。下面是我在项目中实践过的优雅解法：

核心思路：拆分验证责任，复用内置验证能力 #

我们把验证分为两类，分别放在合适的层级，同时通过一个独立的工具类复用数据注解的验证逻辑，避免服务层依赖MVC：

• 基础验证（必填、格式、长度等）：用数据注解定义在领域模型（或DTO）上，一次定义多处复用
• 复杂业务验证（如地址有效性、城市匹配）：放在服务层，因为涉及业务规则和外部依赖（比如谷歌地图API）
• 验证工具类：基于System.ComponentModel.DataAnnotations.Validator实现，让服务层可以验证带注解的对象，不用依赖MVC的ModelState

步骤1：实现独立的验证工具类 #

这个类是关键，它让服务层可以脱离MVC验证带数据注解的对象：

using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;

public static class ValidationHelper
{
    // 验证对象并返回所有错误
    public static IEnumerable<ValidationResult> ValidateObject(object obj)
    {
        var validationResults = new List<ValidationResult>();
        var context = new ValidationContext(obj);
        Validator.TryValidateObject(obj, context, validationResults, validateAllProperties: true);
        return validationResults;
    }

    // 可选：把ValidationResult转成字符串列表，方便返回给控制器
    public static IEnumerable<string> GetValidationErrors(object obj)
    {
        return ValidateObject(obj).Select(result => result.ErrorMessage);
    }
}

步骤2：定义服务层返回结果模型 #

用一个统一的结果类封装操作状态和错误信息，代替抛出异常（异常应该用于意外错误，验证错误是预期的业务场景）：

public class ServiceResult
{
    public bool Success { get; set; }
    public List<string> Errors { get; set; } = new List<string>();

    // 快捷创建成功结果
    public static ServiceResult Ok() => new() { Success = true };
    // 快捷创建失败结果
    public static ServiceResult Failed(IEnumerable<string> errors) 
        => new() { Success = false, Errors = errors.ToList() };
}

// 带返回数据的泛型版本
public class ServiceResult<T> : ServiceResult
{
    public T Data { get; set; }

    public static ServiceResult<T> Ok(T data) 
        => new() { Success = true, Data = data };
    public new static ServiceResult<T> Failed(IEnumerable<string> errors) 
        => new() { Success = false, Errors = errors.ToList() };
}

步骤3：改造服务层，整合两种验证 #

假设你的领域模型Vendor已经带有数据注解：

public class Vendor
{
    public long Id { get; set; }
    [Required(ErrorMessage = "请输入供应商名称")]
    public string Name { get; set; }
    [Required(ErrorMessage = "请输入联系电话")]
    [Phone(ErrorMessage = "电话格式不正确")]
    public string Phone { get; set; }
    [Required(ErrorMessage = "请输入邮箱")]
    [EmailAddress(ErrorMessage = "邮箱格式不正确")]
    public string Email { get; set; }
    [Required(ErrorMessage = "请输入地址")]
    public string Address { get; set; }
    public DateTime? VerifiedAt { get; set; }
}

服务层方法现在可以先验证数据注解，再做复杂业务验证：

public async Task<ServiceResult> CreateVendorAsync(Vendor vendor)
{
    // 1. 验证数据注解
    var validationErrors = ValidationHelper.GetValidationErrors(vendor);
    if (validationErrors.Any())
    {
        return ServiceResult.Failed(validationErrors);
    }

    // 2. 复杂业务验证：检查地址是否符合要求
    var addressValidation = await _googleMapService.ValidateAddressAsync(vendor.Address);
    if (!addressValidation.IsValid)
    {
        return ServiceResult.Failed(new[] { addressValidation.ErrorMessage });
    }

    var isCitySupported = _cityRepository.IsCitySupported(vendor.Address);
    if (!isCitySupported)
    {
        return ServiceResult.Failed(new[] { "地址所在城市不在系统支持范围内" });
    }

    // 3. 执行创建逻辑
    await _vendorRepository.AddAsync(vendor);
    await _unitOfWork.SaveChangesAsync();

    return ServiceResult.Ok();
}

步骤4：控制器层整合服务层错误到ModelState #

控制器只负责接收输入、调用服务、把错误同步到ModelState，保持轻量化：

public async Task<IActionResult> Create([FromForm] VendorViewModel model)
{
    await AuthorizePolicyAsync(AuthorizationPolicyTypes.Vendor.Create);

    // 可选：如果ViewModel也有基础验证，先做一次快速校验
    if (!ModelState.IsValid)
    {
        return View(model);
    }

    // 把ViewModel映射到领域模型（用AutoMapper或手动映射）
    var vendor = _mapper.Map<Vendor>(model);

    // 调用服务层
    var result = await _vendorService.CreateVendorAsync(vendor);

    if (!result.Success)
    {
        // 把服务层的错误添加到ModelState，复用MVC的表单错误展示
        foreach (var error in result.Errors)
        {
            ModelState.AddModelError(string.Empty, error);
        }
        return View(model);
    }

    return RedirectToAction(nameof(Index));
}

方案优势 #

1. 遵循DRY原则：数据注解只在领域模型定义一次，服务层和控制器都可以复用
2. 控制器轻量化：只处理请求转发和视图返回，不包含业务验证逻辑
3. 服务层独立：不依赖MVC组件，专注业务规则和数据一致性，可单独测试
4. 复用内置验证：不用手动编写基础验证逻辑，充分利用.NET的DataAnnotations能力

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