ServiceStack-验证和数据库访问 [英] ServiceStack - Validation and Database Access

查看:56
本文介绍了ServiceStack-验证和数据库访问的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用ServiceStack实现Api.我的解决方案的关键方面之一是积极的验证策略.

I'm implementing an Api with ServiceStack. One of the key aspects of my solution is an aggressive validation strategy.

我使用ServiceStack的ValidationFeature,这意味着如果有IValidator<在应用容器中注册的ReqDto>(或其后代:AbstractValidator< ReqDto>),验证将在服务之前自动运行.

I use ServiceStack's ValidationFeature, meaning that if there is an IValidator< ReqDto > (or its descendant: AbstractValidator< ReqDto >) registered in the app container, validation will automatically run prior to the service.

通过主动验证,我的意思是我检查了所有可能的错误情况,并在验证器级别检查了逻辑验证.结果,我的服务逻辑非常简洁明了.

By aggressive validation, what I mean is that I check all possible error scenarios, and logic validations at the validator level. As a result my service logic is extremely clean and short.

从实用的角度来看,这种服务逻辑与服务验证的独立性确实是一件好事,因为它提供了非常易于阅读和推理的服务逻辑/实现.但是,我开始认为FluentValidation的Rules和RuleSets更适合于简单格式验证,而不是像我正在做的那样直接针对数据库访问(主要用于测试源自请求中提取的ID的404错误).

This independance of Service Logic from Service Validation is something really nice from the practical point of view, because it provides for very easy to read and reason about Service logic/implementation. However, I'm starting to think that FluentValidation's Rules and RuleSets are better suited for simple format validations, and not direct at Database accesses like I am doing (mainly to test for 404 errors originated from ids pulled from the request).

问题:

1:验证逻辑在概念上访问数据库是否不正确?

1: Is it incorrect conceptually for the validation logic to access the database?

2:到目前为止,包括SS源在内,我没有找到一种形式来定义FluentValidation规则,例如:从请求中提取ID,访问数据库,检索实体并抛出404(如果未找到条目).我只使用FV的规则来定义基本格式验证,例如:

2: From what I saw so far, including SS source, I didn't find a form to define a FluentValidation rule for cases such as: pull an Id from the request, access the database retrieve an entity, and throw a 404 if an entry was not found. I only use FV's rules to define basic format validations such as:

RuleFor(x => x.UserName).NotEmpty();
RuleFor(x => x.Password).NotEmpty();

其余的我会手动完成.有解决此问题的人吗?

The rest I do manually. Anyone with a solution to this problem?

注意:这不是有关如何将ValidationResult/ValidationError转换为HttpResult/HttpError的问题.我已经使用SS 3.9.44中引入的ValidationFeature的ErrorResponseFilter进行了介绍. 谢谢

NOTE: This is not a question about how to transform a ValidationResult / ValidationError into an HttpResult/HttpError. I that have covered, by using ValidationFeature's ErrorResponseFilter that was introduced in SS 3.9.44. Thanks

推荐答案

是的,在验证逻辑中执行数据库记录是否存在检查是不正确的,因为这不是验证检查.这就是为什么在示例中未通过这种方式完成的原因.

Yes it is incorrect to perform the check for the existence of a database record in validation logic, because this is not a validation check. Which is why it is not done in the examples this way.

检查记录是否存在是验证检查.通过一个例子来说明这一点:

Checking for the existence of a record is a verification check. By way of an example to illustrate this:

如果您使用信用卡号,则可以使用 Luhn算法来验证该信用额卡号有效.那将在验证器中完成,因为它是验证.

If you take a Credit Card Number, you can use Luhn Algorithm to validate that the credit card number is valid. That would be done in a validator, because it is validation.

但是,仅仅因为您有一个有效的号码并不意味着它存在,所以对于尚未发行的卡,您可能会有一个有效的号码.使用验证器来验证它是否存在是不正确的,因为这是一个验证过程,应在业务逻辑中完成.

But just because you have a valid number doesn't mean it exists, you may have a valid number for a card not yet issued. It would be incorrect to use a validator to verify that it exists, because this is a verification process, and should be done in the business logic.

当您开始使用数据库检查事物的存在时,您就超出了验证的范围,因为您应该只将经过验证的数据传递给数据库.

When you start using the database to check for existence of stuff you are out of the realm of validation, because you should only ever pass validated data to the database.

您可以在此处详细了解验证与验证之间的差异.

You can read more about the difference between validation and verification here.

这篇关于ServiceStack-验证和数据库访问的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆