MS验证块或工作流规则引擎？

Question

对于将要开发的大型应用程序，我们正在选择验证框架。虽然工作流规则引擎不是严格的验证框架，但它可以单独使用，而无需使用工作流基础。它似乎可以灵活地在运行时使用的数据库中指定规则。但是，您似乎无法在代码中指定规则。

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

Answer 1

您的具体要求非常重要。 “灵活”本身并不是一个好的要求，因为它是无法衡量的。如果事情是灵活的话，这是非常主观的。

我不熟悉Microsoft Business Rules Engine，所以我不能对此发表评论。然而，我对Microsoft企业库验证应用程序块（VAB）非常熟悉，它在过去一年中对我很有帮助。它有几个功能，使我可以灵活处理我正在处理的情况：

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

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

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

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

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