c# - 根据 DTO、实体模型或其他东西验证服务层中的数据？

Question

我正在处理一个 ASP.NET MVC 项目。在该项目中，我有一个服务层，它接受用于 CRUD 操作的 DTO。当我需要验证业务逻辑时，验证器是否应该完全接受 DTO、实体模型或其他东西？

例如:

public class ProductService: IProductService
{
    public ValidationResult CreateProduct(ProductDTO productDto)
    {
       //call productValidator.Validate(productDto) on the DTO here?

        Product productEntityModel = mapper.Map<Product>(productDto);

        //or, call productValidator.Validate(productEntityModel) on the Entity model here?

        if(validationResult.Valid)
        {
            _dbContext.Products.Add(productEntityModel);
            _dbContext.SaveChanges();
        }

        return validationResult
    }
}

一些想法:

• 我在网上看到一些关于创建 POCO 的讨论，其中可以包含验证逻辑(而不是使用验证服务)甚至其他业务逻辑。这是有道理的，但它是必须管理和维护的产品的又一种“表现形式”。
• 根据 DTO 进行验证似乎更合理一些，因为调用者正在向服务发送消息？

感谢您的帮助!

Answer 1

When I need to validate business logic, should the validator accept DTOs, Entity Models, or something else entirely?

通常，我们在 ViewModel 类中使用 DataAnnotations 执行验证，以便我们可以返回用户友好的 ModelError。例如，

public class LoginViewModel
{
   [Display(Name = "Username")]
   [Required(ErrorMessage = "Please enter your username.")]
   public string UserName { get; set; }
}

public async Task<ActionResult> Login(LoginModel model, string returnUrl)
{
   if (ModelState.IsValid)
   {
      ...
      ModelState.AddModelError("", "User is not authorized!");
   }
   ...
}

虽然您可以验证 ProductService 中的一些业务逻辑，但您不能返回 MVC ModelError，因为服务/存储层不应该依赖于 ASP.NET MVC(或任何 UI组件)。

Service/Repository Layer 中的大多数错误都是意外错误，而不是用户错误。我们通常不会在 NLog 或 Log4Net 中记录这些错误，并将用户重定向到自定义错误页面。