我已经设置了一个小GitHub project，试图解决我正在寻找的项目问题。{I}我想知道这是否已经解决了问题，或者我可能会涉及需要更多研究的问题。
我将结构化验证应用于我们的数据模型，这是（在此示例中）比萨饼订购Web应用程序。这意味着模型中的每个对象（Order, MenuItem）都具有validate()函数。它以递归方式遍历对象＆＃39;验证函数并返回一个布尔结果。这是拼图的结构化验证部分，实现起来相当简单，如我在GitHub上的示例所示。
我的问题的主要部分涉及验证每个对象内的多个关注级别。例如，您可能希望验证一个对象，以便稍后保存到我们的数据库中（我知道这通常会在sessionStorage中进行披萨订购，但这对于更复杂的业务来说是一个愚蠢的例子，所以请耐心等待me），您还需要验证用户点击＆＃34;提交订单＆＃34;，＆＃34; next＆＃34;，或者您的UI为数据上的任何给定用户操作提供的任何操作。也许您希望同样的验证功能也适用于餐厅中的自助服务终端......但在这种情况下，您的业务要求与在线订购的用户不同。
在我的示例中处理此方法的方法是在整个验证代码中遵循级别索引的约定。例如，级别索引0 表示数据通过基线应用程序假设或要求，例如属性的类型。 级别索引1 表示用户提供的属性值的任何假设，例如电子邮件地址属性与常规快递匹配，或者价格值大于或等于0.01。最后，级别索引2 表示数据通过任何可能或可能不依赖于外部状态的业务需求。我们的对象的默认签名＆＃39;验证函数是validate(level=0, extState={})。因此validate(0) === true表示我们可以存储我们的数据，但我们需要validate(2, {action: 'order'}) === true来确保订单数据通过制作和提供披萨所需的所有要求。请注意，按照惯例，validate（2）还将验证索引级别1和0，因此我们始终可以保证数据兼容并在验证业务需求时满足期望。我们的对象是第2级。验证者应该向我们的用户界面传达某些字段是必需的＆＃34;促进功能。
请记住，能够在单个结构化验证实现中处理所有这些的好处是打算在客户端和服务器上工作。此外，关注度指标水平的惯例应该消除对低级别验证问题的大量重复工作。您只需要为任何给定的业务目的定义一次数据模型的约束。
注意：关于安全性，GitHub上的README将安全性称为＆＃34;阴影级别＆＃34;验证问题，因为这确实需要在整个堆栈的每个级别实现。因此，您可以在任何验证级别索引上进行安全检查，并且还可以继续在我们的对象模型之外，在我们的服务器端控制器代码或其他地方处理特定的安全问题。