我正在使用ServiceStack实现Api。我的解决方案的一个关键方面是积极的验证策略。
我使用ServiceStack的ValidationFeature，这意味着如果有一个IValidator＆lt; ReqDto＆gt; （或其后代：AbstractValidator＆lt; ReqDto＆gt;）在应用容器中注册，验证将在服务之前自动运行。
通过积极验证，我的意思是我检查所有可能的错误情况，以及验证器级别的逻辑验证。因此，我的服务逻辑非常简洁。
从实际的角度来看，服务验证中的服务逻辑的独立性是非常好的，因为它提供了非常容易阅读和推理服务逻辑/实现。但是，我开始认为FluentValidation的规则和规则集更适合简单的格式验证，而不是直接在我正在进行的数据库访问（主要是测试源自请求中提取的ID的404错误）。
问题：
1：验证逻辑在概念上是否错误地访问数据库？
2：从我到目前为止看到的，包括SS源代码，我没有找到一个表单来定义FluentValidation规则，例如：从请求中提取Id，访问数据库检索实体，并抛出一个404如果找不到条目。我只使用FV规则来定义基本格式验证，例如：
RuleFor(x => x.UserName).NotEmpty();
RuleFor(x => x.Password).NotEmpty();
其余的我手动做。有解决这个问题的人吗？
注意：这不是关于如何将ValidationResult / ValidationError转换为HttpResult / HttpError的问题。通过使用SS 3.9.44中引入的ValidationFeature的ErrorResponseFilter，我已经介绍过了。 感谢
答案 0 :(得分：7)
是的，在验证逻辑中检查是否存在数据库记录是不正确的，因为这不是验证检查。这就是为什么不以这种方式在示例中完成的。
检查是否存在记录是验证检查。举例来说明这一点：
如果您使用信用卡号码，则可以使用Luhn Algorithm来验证信用卡号是否有效。这将在验证器中完成，因为它是验证。
但仅仅因为你有一个有效的数字并不意味着它存在，你可能有一个有效的号码用于尚未发行的卡。使用验证器来验证它是否存在是不正确的，因为这是一个验证过程，应该在业务逻辑中完成。
当您开始使用数据库检查是否存在您不在验证范围内的东西时，因为您应该只将验证数据传递给数据库。