DTO-Endpoint 验证是否没有将业务逻辑移至错误的层？

Question

在 asp.net web api 中，模型验证是通过 DataAnnotations 或 FluentValidation 框架完成的。

根据MS验证已完成：http://www.asp.net/web-api/overview/formats-and-model-binding/model-validation-in-aspnet-web-api

这是上面链接中的示例：

public class Product
{
    public int Id { get; set; }
    [Required]
    public string Name { get; set; }
    public decimal Price { get; set; }
    [Range(0, 999)]
    public double Weight { get; set; }
}

Microsoft 似乎在简单示例中使用了 DTO/业务模型/持久性对象的组合...太糟糕了...它同时传递到客户端和数据库。

问题：像权重这样的东西必须在0到999之间，这不是属于服务层而不是应用层吗？

对我来说，这是业务逻辑，因为此字段类型（双精度）没有数据库限制，因此它肯定没有数据提供者逻辑。

Answer 1

像权重这样的东西必须在0到999之间，这不是属于服务层而不是应用层吗？

模型验证不一定是领域。

例如，ASP.NET WebAPI 使用模型验证来实际执行 HTTP 实体验证。这是一个有价值的验证，因为它意味着意外的 HTTP 请求可能无法到达 API 控制器，这很好，因为您可以避免在执行实际域逻辑之前执行大量代码。

由于数据注释和模型验证是跨层功能，因此您可以使用相同的数据注释属性和验证器来验证 DTO 和域模型，并且不会破坏良好的关注点分离。

对我来说，DTO 验证更像是一份合同：我不会处理数据不符合我期望的形式的请求。我不打算实施深度验证，但至少我收到了预期格式的所需数据。

最终，您需要决定应用于软件层的正确验证规则。也许 DTO 不应该验证权重应该在 0 到 999 之间，但它应该检查权重是否等于或大于 0，而域层应该根据具体的域规则/规范进行验证。如果某些域要求权重应小于 999，请在此处添加此验证。从 DTO 接收数据的任何域都不会接收负权重，而域可以验证权重是否在 0 到 999 之间。