使用自定义规则进行动态验证

Question

我使用 .Net 语言已有 4 年了。我使用 WCF、ASP.NET（用于 Web 应用程序）和 C#（用于 Windows 应用程序）开发 3 层和 5 层应用程序。每次我开始一个项目时，业务规则和验证都是一个问题。

我应该在哪里放置自定义验证规则（按钮单击事件、页面加载或类中的 setter/getter 中）？

如果项目很大并且只有一个字段，而不是 5 个字符应该是 7 个字符 - 为什么我应该重建整个项目（或业务类项目）？

我想如果我有一个包含自定义规则的文件，那么当需要更改时我可以简单地在其中放置一个新规则。我读过互联网上的一些文章，它们为此目的提供了基于 XML 的文件，但这似乎有问题，因为：

• 没有智能感知，并且 XML 文件中的错误很难找到
• 我们必须编写自定义 XML 解析器
• 因为此方法需要大量转换，速度非常慢

我的问题：

是否有设计模式或其他使用 .NET 方法（反射、表达式树、Lambda 表达式、动态、DLL 的运行时创建等）进行动态验证的方法自定义规则？

---

编辑 1)

属性怎么样？我们可以将它们与自定义验证的反射一起使用吗？我们可以用这种方法根据另一个属性（例如 P1 应该是 P2+1）验证一个属性吗？

Answer 1

表示业务规则的最佳方式是在 xml 中。要充分利用此表示法，您应该从定义规则引擎数据模型的结构开始，即回答这些问题。

1. 规则是什么？
2. 规则可以分类吗？
3. 规则是否包含常见属性（属性），例如允许的值、格式等？

完成此操作后，创建一个虚拟规则 xml，然后基于此 xml 派生一个 xml 模式。 xsd.exe 工具可以提供帮助您在创建架构时。如果您可以使用 Altova XmlSpy 等工具，则创建架构会更容易。

至于你的具体问题的答案，

• 我们无法使用 Intellisense，如果 XML 文件中有错误，则很难找到它。

一旦架构到位，Visual Studio 就会为创建 xml 提供充足的支持（包括智能感知和验证）。

• 我们应该编写一个自定义 xml 解析器

这不是必需的，XmlSerializer 类 提供序列化/反序列化逻辑，即将规则xml 转换为规则数据模型，反之亦然。

• 由于该方法需要多次转换，所以速度非常慢

与硬编码规则（作为类嵌入到程序集中的规则）相比，这是部分有效的观点，但这种方法的灵活性远远超过了任何性能缺点。如果规则发生变化，您不需要重建解决方案。在大多数情况下，性能影响很小。

除非您有严格的性能标准，否则 xml 方法是实现规则引擎的首选方法。请记住，架构的耦合越松散，运行时的灵活性就越高，但会对性能产生负面影响。

示例规则

<RulesEngine>
  <Rules>
    <Rule Id="Rule1">
      <Function>
        <Equals>
          <Property name="Property1" classId="MyClassId"/>
            <Sum>
              <Property name="Property2" classId="MyClassId"/>
              <Constant type="UInt16" value="1"/>
            </Sum>
          </Equals>
        </Function>
      </Rule>
    </Rules>
    <Classes>
    <Class name="MyNamespace.MyClass" Id="MyClassId">
      <Property name="Property1" type="UInt16"/>
      <Property name="Property2" type="UInt16"/>
    </Class>
  </Classes>
</RulesEngine>

规则引擎需要解释该规则并推断出相应的含义。

Answer 2

查看 FluentValidation。它使用表达式，您可以创建条件验证（例如，如果该属性满足某些条件，则验证这些属性）。 FV 可能不是开箱即用的动态，但您可以获得智能感知、表现力和类型安全。它的通用性意味着它运行得相当快。您可以通过传入验证委托或自定义验证器来注入一些运行时动态，它们几乎可以执行您能想到的任何操作。

这确实意味着您必须重新编译，但您可以将验证器放在单独的程序集中。验证器不出现在类中/类中确实有意义，因为您经常发现验证是在上下文中执行的。例如，如果一辆汽车拥有所有轮子，那么它可能是有效的。但是，如果您尝试驾驶它并且它没有汽油电池，那么它对于驾驶来说是“无效”的。也就是说，我会将规则定位为“接近”它们正在验证的内容，因为它们是您的域的一部分。

如果您需要一个属性规则，该规则依赖于一个或多个属性（包括其自身），并且需要一条自定义消息（如果不满足该规则的条件），则可以执行此操作。考虑一下：

RuleFor(x => x.P1)
    .Must(x => x.P1 > x.P2)
    .Message("P1 must be one more than P2. P1 was {0}; P2 was {1}", x=>x.P1, x=>x.P2);

给出一个简单的比较，但你可以做更复杂的事情。