【问题标题】:Data validation: fail fast, fail early vs. complete validation数据验证:快速失败、早期失败与完整验证
【发布时间】:2011-02-03 21:56:39
【问题描述】:

关于数据验证,我听说选项是“快速失败,早期失败”或“完全验证”。第一种方法在第一个验证错误上失败,而第二种方法建立一个失败列表并显示它。

我在服务器端和客户端数据验证的上下文中对此感到疑惑。哪种方法适合什么情况,为什么?

我个人对客户端数据验证的偏好是第二种方法,它通知用户所有失败的约束。尽管我认为这取决于所涉及的业务逻辑,但我没有足够的信息对服务器端发表意见。

【问题讨论】:

    标签: validation fail-fast-fail-early


    【解决方案1】:

    对于无效输入或丢失数据等琐碎错误,您可以自行决定为用户制作系统的方便程度。例如,如果有人将完整的数据电子表格导入系统并且第一行失败并且您说“第一行失败”,这可能会非常烦人。用户修复第一行,导入并收到“第二行失败”消息。想象一下有 65536 行。您已经知道您不会对数据做任何事情,但是您想让用户的生活更轻松吗?同样,这些是我正在讨论的微不足道的错误,当然您将设计一个在处理之前验证所有数据的系统。

    对于更严重的错误,或者您没有预料到或者不仅仅是验证问题,请恢复为快速而严格地失败

    【讨论】:

      【解决方案2】:

      这令人困惑的部分原因是人们没有将正交性作为标准的一部分来讨论。 'Fail-early' 很有用,以便错误在发生的地方而不是下游被捕获。但是对于正交故障,没有下游或多个下游。

      例如,大多数用户表单都充满了许多独立的问题,例如用户名、密码、电子邮件。由于它们是独立的,请等到所有 3 个都到达,然后立即描述所有错误。让用户经历三个提交-检查-投诉周期是荒谬的。

      【讨论】:

      • 谢谢!这解释得很好。
      • 很高兴您发现它有帮助!
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2012-07-14
      • 1970-01-01
      • 1970-01-01
      • 2012-03-15
      • 1970-01-01
      相关资源
      最近更新 更多