0

对于将要开发的大型应用程序，我们正在选择验证框架。虽然 Workflow Rules 引擎严格来说不是一个 Validation 框架，但它可以在不使用 Workflow 基础的情况下单独使用。它似乎为在运行时使用的数据库中指定规则提供了灵活性。但是，您似乎无法在代码中指定规则。

如果更大的灵活性是要求之一（不一定需要业务分析师编辑规则），您更喜欢两者中的哪一个，为什么？

4

1 回答 1

2

您的确切要求是什么非常重要。“灵活”本身并不是一个好的要求，因为它是不可衡量的。如果某些东西是灵活的，这是非常主观的。

我不熟悉 Microsoft 业务规则引擎，因此无法对此发表评论。然而，我对 Microsoft 企业库验证应用程序块 (VAB) 非常熟悉，它在去年为我提供了很好的帮助。它具有几个功能，可以灵活地处理我正在处理的情况：

  • 它允许定义验证声明（使用属性）和使用外部配置文件（这在生成实体时非常有用）。
  • 它包含一组可以使用的默认验证器，并且可以编写自定义验证器。
  • 它允许验证单个属性，并允许您将多个属性作为一个组进行比较（通过使用自我验证或自定义验证器）。
  • 它允许单独验证对象以及对象图。
  • 它允许您定义多个“规则集”，例如允许您定义一组硬错误和一组警告。

VAB（或整个企业库）允许您编写自定义配置源 (IConfigurationSource)，它允许您在任何地方定义业务规则。所以理论上你可以将它们存储在数据库中，但是你必须自己编写这样的配置源，这将是相当多的工作。特别是当您希望您的业务分析师能够定义验证并使用某种编辑工具更新数据库时，它认为使用 VAB 完成这将是非常糟糕的。

如果确实需要业务人员自己编写这些规则，希望您有支持此要求的流程。例如，他们将如何测试他们的更改是否正确？您不希望您的业务分析师直接对生产数据库进行更改。

但请考虑一下。如果要测试规则，我希望这些规则不会直接在您的生产数据库中更改，否则您将在事后进行测试。因此，分析师将在他们自己的环境中更改规则，您可能会将新规则从该环境发布到测试环境，然后发布到验收环境，最终发布到生产环境。如果您正在采取这些步骤，您是否还应该使用数据库来存储这些业务规则？使用配置文件比使用数据库更容易。部署将只是文件副本，而不是将多个表的内容从数据库复制到数据库。

我对其他人对他们熟悉的验证框架的看法很感兴趣。

于 2010-02-16T15:28:18.253 回答