EntLib 验证规则操作顺序?
决定 EntLib 验证规则执行顺序的因素:
考虑以下情况:
<ValidatorComposition(CompositionType.And, Ruleset:="Default")> _
<NotNullValidator(MessageTemplate:="Transaction ID is required.", Ruleset:="Default")> _
<TypeConversionValidator(GetType(Int64), MessageTemplate:="Transaction ID must be numeric.", Ruleset:="Default")> _
<RangeValidator("0", RangeBoundaryType.Exclusive, "0", RangeBoundaryType.Ignore, MessageTemplate:="Transaction ID may not be 0.", Ruleset:="Default")> _
<StringLengthValidator(1, RangeBoundaryType.Inclusive, 19, RangeBoundaryType.Inclusive, MessageTemplate:="Transaction ID must be between 1 and 19 characters in length.", Ruleset:="Default")> _
当对象实例化中缺少 TransactionID 时,预计会附加以下错误字符串:
Transaction ID must be numeric.Transaction ID must be between 1 and 19 characters in length.Transaction ID may not be 0.Transaction ID is required.
但是,似乎每个错误的实际顺序可能与时间不同到时间了。出现相同的错误,但顺序不同。
我通过单元测试发现了这一点,我知道数据没有改变,曾经通过的测试现在失败了。
有没有人遇到过这个,并有解释?
谢谢。
What determines the order of execution of an EntLib validation rule:
Given the following:
<ValidatorComposition(CompositionType.And, Ruleset:="Default")> _
<NotNullValidator(MessageTemplate:="Transaction ID is required.", Ruleset:="Default")> _
<TypeConversionValidator(GetType(Int64), MessageTemplate:="Transaction ID must be numeric.", Ruleset:="Default")> _
<RangeValidator("0", RangeBoundaryType.Exclusive, "0", RangeBoundaryType.Ignore, MessageTemplate:="Transaction ID may not be 0.", Ruleset:="Default")> _
<StringLengthValidator(1, RangeBoundaryType.Inclusive, 19, RangeBoundaryType.Inclusive, MessageTemplate:="Transaction ID must be between 1 and 19 characters in length.", Ruleset:="Default")> _
When TransactionID is missing from an object instantiation, the following appended error string would be expected:
Transaction ID must be numeric.Transaction ID must be between 1 and 19 characters in length.Transaction ID may not be 0.Transaction ID is required.
However, it would seem that the actual order of each error can differ from time to time. The same errors appear, but in a different order.
I found this out through unit testing, where I knew the data had not changed, and the once passing tests were now failing.
Has anyone ran into this, and have an explanation?
Thanks.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论