验证应用程序块问题

发布于 2024-08-13 09:34:54 字数 343 浏览 6 评论 0原文

有人使用过企业库中的验证应用程序块吗？有成功吗？

无论如何，我的问题是关于验证数字唯一标识符。假设我有一个 Product 类，其中 ProductId 属性代表产品的唯一标识符。它是数字。该标识符不能小于 1，它必须大于 1。我不知道使用验证应用程序块选择什么验证类型。我正在考虑尝试范围类型，但它需要 2 个值，一个较低值和一个较高值。

验证业务对象属性的另一个问题。这是测试业务对象的最佳方法吗？我只想指定一次验证规则，然后我想跨不同层使用它们，例如 ASP.NET。我从来没有以这种方式验证业务对象，只是在客户端。有人可以告诉我最好的路线是什么以及我的方向是否正确吗？

有人可以建议吗？

谢谢布伦丹

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

倾城月光淡如水﹏ 2024-08-20 09:34:54

VAB 经验

我已经使用 VAB 对项目进行验证。我想说这很好。我不会说它很棒。到目前为止没有重大问题。我发现我们确实需要创建一些自定义验证器，因为我们的需求没有立即得到满足。所以它是可扩展的，这是很好的。我们确实遇到了配置工具无法解析我们的类型的问题（我认为这是加载依赖项时的错误）。代码运行良好，但我们必须在没有工具的情况下进行一些配置。

验证数字唯一标识符

使用范围验证器您走在正确的轨道上。请注意，每个范围（上限和下限）可以有 3 种不同的类型：包含、排除和忽略。这应该涵盖大多数情况。在您的情况下，您可以将上限指定为忽略，将下限指定为 1（含 1）（假设您希望 ProductId 为 1 或更大）。

在配置中，这看起来像：

   <properties>
      <property name="ProductId">
        <validator lowerBound="1" lowerBoundType="Inclusive" upperBound="0"
          upperBoundType="Ignore" negated="false" messageTemplate="Oops...too low." messageTemplateResourceName=""
          messageTemplateResourceType="" tag="" type="Microsoft.Practices.EnterpriseLibrary.Validation.Validators.RangeValidator, Microsoft.Practices.EnterpriseLibrary.Validation, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
          name="Range Validator" />
      </property>
    </properties>

验证业务对象属性

听起来您走在正确的轨道上。您绝对应该始终验证业务（或服务）层的输入。如果您还想在客户端层中执行验证，那么您可以跨层共享您的配置或实体（业务对象就是您所说的它们），但您必须确保配置或实体在层之间同步。如果您在两个不同的层中进行验证，则需要考虑的另一件事是如何显示 ValidationResults。 VAB 与 ASP.NET 集成，但一旦调用业务层，您将无法进行该集成，因此您将需要另一种（自定义）方式来显示这些错误。（这可能就像将错误转储到的标签一样简单。）

现在您会说：啊，但是如果我在 Web 层中进行验证，那么我应该捕获 ASP.NET 中的所有验证错误，并且一切都很好一起。真的。但这引出了我的最后一点。

VAB可能能够处理所有验证，但它可能无法处理复杂的验证。如果您进行跨字段（或跨对象）验证，VAB 不会表现良好。此外，您可能需要在业务层中执行一些您不想在 Web 层中执行的自定义验证（例如，某些验证可能依赖于无法从 Web 层访问的数据库或外部服务）。因此，您最终可能会使用两种不同的实现来显示验证/错误消息。

VAB Experience

I have used the VAB to on projects for validation. I would say that it is good. I wouldn't go so far as to say it's great. No major issues so far. What I did find was that we did need to create some custom validators because our needs were not addressed out of the box. So it's extensible which is good. We did have issues with the configuration tool not being able to resolve our types (I think it's a bug in loading dependencies). The code runs fine but we had to do some configuration without the tool.

Validating a Numeric Unique Identifier

You're on the right track with the range validator. Be aware that each range (upper and lower) can have 3 different types: Inclusive, Exclusive and Ignore. This should cover most cases. In your case, you can specify the upper bound as ignore with the lower bound as 1 inclusive (assuming you want ProductId to be 1 or greater).

In configuration this would look like:

   <properties>
      <property name="ProductId">
        <validator lowerBound="1" lowerBoundType="Inclusive" upperBound="0"
          upperBoundType="Ignore" negated="false" messageTemplate="Oops...too low." messageTemplateResourceName=""
          messageTemplateResourceType="" tag="" type="Microsoft.Practices.EnterpriseLibrary.Validation.Validators.RangeValidator, Microsoft.Practices.EnterpriseLibrary.Validation, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
          name="Range Validator" />
      </property>
    </properties>

Validating Business Object Properties

It sounds like you are on the right track. You should definitely always validate input to your business (or service) layer. If you also want to perform validation in the client tier then you can share your configuration or entities (business objects is what you called them) across tiers but you will have to ensure that the config or entities are synchronized between tiers. Another thing to consider if you are validating in two different tiers is how the ValidationResults will be displayed. VAB has integration with ASP.NET but once you call the business tier you won't have that integration so you will need another (custom) way to display those errors. (That may be as simple as a Label to dump the errors to.)

Now you're saying: ah, but if I validate in the web tier then I should catch all of the validation errors in ASP.NET and it all works nicely together. True. But that brings me to my last point.

VAB may be able to handle all validation but it probably won't be able to handle complicated validations. VAB is not going to do well if you have cross field (or cross object) validations. Also, you may need some custom validation in your business tier that you don't want to execute in the web tier (e.g. perhaps some validation depends on databases or external services that are not accessible from the web tier). So it's possible that you might end up with two different implementations to display validation/error messages.

回复收藏 0 原文

面如桃花 2024-08-20 09:34:54

为什么不将验证器的上限设置为等于您正在使用的任何类型的最大值？

例如，如果您使用 Int32，请执行以下操作：

[RangeValidator(1, RangeBoundaryType.Inclusive, 
Int32.MaxValue, RangeBoundaryType.Inclusive)]

至于最佳实践，集中验证始终是一项棘手的工作，而企业库块是解决此问题的一个非常好的解决方案。我认为这种方法很好，但它有其局限性（解决这个问题的所有尝试也是如此）。

Why not set the upper bound of the validator equal to the maximum value of whatever type you are working with?

For example, if you are using Int32, do this:

[RangeValidator(1, RangeBoundaryType.Inclusive, 
Int32.MaxValue, RangeBoundaryType.Inclusive)]

As for best practice, centralizing your validation is always a tricky job and the Enterprise Library blocks are a very good solution for this problem. I think this approach is fine but it has its limitations (as do all attempts to solve this problem).

回复收藏 0 原文

~没有更多了~