在整个技术栈中进行动态输入--在哪里执行数据有效性？

Question

在过去的一两年里，我一直在我的副业项目中使用新的技术。作为一名web开发人员，我已经从以下几个方面着手：

‘经典’技术栈

1. Web浏览器将表单发布到..。
2. 一个C#编码的web应用服务器端，与.
3. 通过XML的外部服务，最终.
4. 将应用程序状态写入SQL数据库。

使用一种非常不同的安排：

全动态技术栈

1. 网页浏览器提交XmlHttpRequests给..。
2. 一个JavaScript编码的Node.js服务器端，与.
3. 其他外部服务通过JSON中的RESTful服务最终.
4. 将应用程序状态写入无SQL数据库。

我的整个堆栈在任何地方都完全没有类型或模式的强制执行。

现在，在使用其他人的web服务时，这一点已经很好了。在SQL数据库被丢弃之前(以及它们的DB模式)，它甚至可能还不错。但现在我被困在：

在哪里以声明方式定义业务域数据的有效结构？

在公开我的任何项目之前，我想要强制执行数据有效性--毕竟，怎样才能阻止某人向我的服务提交无效的数据，并将其作为一个免费的数据库提供者使用呢？在某种程度上，必须强制执行“此web服务将只接受至少一个X的集合，X必须包含A、B和可选的C”。

我想到的第一个解决方案是通过一大块命令式代码/if-else/等等在我的node.js中进行验证。

我一直在使用CouchDB，有一段时间我认为最好将验证代码放在_update处理程序中。至少，作为持久性的一部分，我们正在执行验证，但它仍然是一个丑陋的命令式块。

接下来，我研究了JSON模式语言。据我所知，目前还没有标准，而且我对所提供的多种解决方案也没有信心。我可以自己滚，但那样我只会扩展非标准的JSON模式语言。

XML？我可以将X放回AJAX中，并让它们在服务器端验证所有模式。然而，这似乎不符合软件开发的趋势。也不会使用XML数据存储而不是JSON /BSON MongoDB持久化层。

所以我被困住了。想法？

当我在技术栈中没有使用静态面向对象的语言和没有模式绑定的SQL数据库时，我应该在哪里声明地定义我的业务域数据的有效结构？是否有可能在某个地方存在某种静态类型(或DB模式或已验证的XML)才能使技术堆栈具有任何意义？如果是，在哪里？

Answer 1

在我看来，您将创建一个内平台来弥补您所选择的语言固有的语义不足。

即使是模式定义(无论是XML，还是JSON模式或猫鼬模式)也不能为您提供静态分析的安全性。您真正能够使用它们的是确保您的系统不会默默地遇到未定义的行为并最终失败。

我不太清楚你为什么不使用一种语言，因为它只提供了现成的语言。使用动态类型化语言和将类型约束嵌入到其中似乎会将这两个世界中最糟糕的情况结合起来。更重要的是，因为现代静态类型化语言能够隐式推断这些约束的大部分。

就我个人而言，我建议你看看哈克的S JavaScript后端。有一个专门针对Haxe的node.js开发的站点 --您可以从那里开始。Haxe的匿名类型可以快速地以一种类型安全的方式绑定JSON源，而不需要任何运行时开销。不过，如果您愿意，它的元编程设施允许您在编译时自动生成验证代码。

当然，到目前为止，Haxe并不是以类型错误方式以JavaScript为目标的唯一选择。所以，如果你觉得你需要静态输入的好处，你应该花时间去寻找一种你喜欢的语言，它实际上把这些信息嵌入到静态可分析的语义中。

Answer 2

完全放弃类型的概念。

动态输入的全部要点，至少在大多数正确的语言中是这样的，那就是大多数时候您不需要考虑类型。类型检查在预编译语言中是有意义的，因为编译器可以在您尝试运行代码之前捕获大量错误，但是当您的代码被解释或JIT编译时，静态类型检查的好处是微不足道的，而不是与动态编程必须提供的额外灵活性进行权衡。

与其验证类型，不如验证值--也就是说，如果您想要的是数值，那么运行一个“is -数值”检查。如果希望某物具有特定属性，请检查该属性是否存在。如果你想要某物在某一范围内，检查它实际上是否在这个范围内。等。等。

这有两种哲学:更传统的检查，即在除以a除以b之前，确保b是非零的；请求宽恕比许可路径更容易，也就是说，您只需将a除以b，然后再捕获除以零的例外。

不幸的是，据我所知，没有任何有意义的声明方式可以做到这一点。但是，在动态规划中，代码和数据之间的界限更加模糊--代码也是您可以操作的数据，数据可以充当代码的角色。验证JSON对象的一段javascript代码只是另一段文本，您可以将其视为普通的旧数据；您甚至可以在运行时生成该文本，然后执行它(尽管您应该非常小心，特别是在代码生成过程中使用来自不可信源的数据时)。

至于模式，同样，严格检查给定的JSON对象是否与模式匹配是很少需要的--相反，只需检查所需的属性是否存在，以及值级不变量是否有效。如果存在额外的属性，那就好--你只需忽略它们。如果有什么东西丢失了，你可以保释，或者替代一个默认值。如果有错误的类型，您也可以保释(在需要数字的地方找到一个非数字字符串)，或者您可以优雅地恢复(替换默认值、圆整、截断、转换为布尔值等)。

另一件需要考虑的事情是，XML远比JSON复杂得多-- XML具有名称空间、属性、实体，您需要决定如何在您的语言和XML表示形式中的对象之间封送。在JSON中，选择通常是显而易见的--它要么是标量(int、float、string、boolean、null)、一个简单的列表(数组)，要么是键值集合(object)。

不幸的是，很少有语言(如果有的话)具有透明类型转换的权利-- Javascript、PHP、Python，它们都偶尔需要显式的类型杂耍，所以您将无法达到理论上的理想情况。

Answer 3

既然你的程序栈不关心类型，你为什么要。

答案是您的用户可能。因此，您要做的是强制执行适用于您的数据的任何业务规则。

这可以由JavaScript对输入的表单进行编码，在收到请求时将验证编码到Node.js服务器代码中，或者甚至在xsd中对规则进行编码，并让解析器验证您的Node.js输入。

关键是您实现了业务规则验证，而不是技术验证。也就是说，你应该检查规则，比如“001到700之间的三位数”，这对你的最终用户来说意味着什么，而不是“这个数字”。因此，如果您的用户认为“圣诞节前一晚”是一个有效的日期，而您的应用程序可以接受它，那么它就是一个有效的日期。