使用 JSON 模式进行 DRY 用户输入验证（客户端、服务器端）

Question

作为一个广泛的测试用例的一部分，我正在构建一个基于 ajax 的类 CMS 应用程序，它为各种文档类型提供 CRUD 功能，例如：文章、标签等。

在服务器和客户端上，我正在考虑使用 JSON 模式 (http://json-schema.org/) 作为一种以 DRY 方式进行用户输入验证的方式（即：1 个验证模式，同时用于服务器和客户端，没有重复代码等等）。这看起来很棒，因为：

• JSON 模式在 JS 和 Java 中都实现了，所以理论上一个模式可以处理客户端和服务器端验证

• 所有 CUD 操作请求和响应都是 JSON（通过 ajax）

但是，除了对用户输入的常规验证之外，我还想对服务器进行一些额外的检查（例如：检查用户想要创建的标签的名称是否已经存在）

理想情况下，我希望将这些类型的检查包含在我的通用服务器端验证代码中（如前所述，它将基于 JSON 模式）。但是，我并不完全相信这是正确的方法，因为这些额外的检查不仅仅基于提供的 JSON 数据，而是需要额​​外的数据来验证（例如：系统中现有标签的名称来检查是否一个标签名已经存在）。

那么，在服务器端的基于 json-schema 的验证框架中加入额外的检查（如上述检查）是否是一个好主意（设计/架构方面）？这会是一个优雅的解决方案吗？或者你会把它们完全分开吗？如果不是，为什么不呢？您建议在客户端和服务器端验证方面采用什么其他替代方法来保持 DRY？

你怎么看？

以下文本案例的一些附加上下文/目标，以获取一些背景信息。

谢谢， 吉尔特-扬

---

一些背景/目标：

• 使用 REST 方法的基于 ajax 的 CMS

• CUD 请求是通过 ajax 使用休息方法执行的（即：分别映射到 POST、PUT、DELETE）。请求和响应都是通过 JSON 完成的。

• 不带表单的 CMS。而是使用就地编辑（例如使用 Aloha-editor：http://www.aloha-editor.org/

• 保持干燥。

  1. 模板：通过 Mustache 模板在客户端和服务器端完成。初始渲染和通过ajax的增量渲染都是基于1和同一个模板完成的。我想找一些不同于 Mustache 的东西（因为它缺乏表现力），但它至少适用于这个原型。 （有关替代方案，请参阅上一个问题，我仍在寻找答案：Client-side templating language with java compiler as well (DRY templating) ）

  2. DRY 输入验证：如上所述

---

验证流程（失败时）：

1. 用户创建/更新/删除项目。

2. 客户端上的验证失败会立即向用户反馈要修复的内容。 （Javascript JSON-schema-validator 理想情况下会返回格式化给用户的 JSON）

3. 当客户端验证成功时，使用 ajax 执行 CUD 操作。

4. 如果服务器端验证失败，则返回状态码 400（错误请求），其中包含由 jquery 的错误回调拾取的验证失败的 Json 对象

   $.ajax({
       ....
       error: function(xhr, status, error) {
           var validationJSON = JSON.parse(xhr.responseText);
           //handle server-side validation failure 
       },
       ....
   });
   

5. 将包含服务器端验证失败的 JSON 对象呈现给用户（类似于客户端）

Answer 1

在服务器上的一个地方（每个模型）有一个单一的验证定义是非常有可能的，也是最令人满意的事情之一，然后可以为客户端和基于 AJAX 的验证生成适当的 JS。

PHP 的 Yii 框架具有出色的架构，可以以一种优雅的方式完成此任务，将所有验证规则一起存储在模型中（根据需要划分为适当的“场景”）。从那里开始，只需翻转几个开关即可使特定的表单客户端或 AJAX 可验证。我相信 Yii 的接口是基于 Rails 的。

无论如何，我强烈建议您从 Yii 的设计中查看以下要点；即使你不懂 PHP，也可以从中汲取灵感：

• CModel::rules() => 模型验证规则的 DRY 源
• CActiveForm => 用于根据模型属性生成表单元素
  • 参见例如CActiveForm::textField()
• CValidator => 为the ability to client-validate 提供的验证器基类

我认为追求 DRY 验证规则声明是明智的，根据我的经验，实现 100% 并仍然拥有丰富的表单和丰富的验证规则并非不现实。 （当您不必管理所有客户端验证 JS 时，您会热爱生活吗……）

希望这会有所帮助。