关于数据验证,我听说选项是“快速失败,早期失败”或“完全验证”。第一种方法在第一个验证错误上失败,而第二种方法建立一个失败列表并显示它。
我想知道在服务器端和客户端数据验证的上下文中。哪种方法适合什么情况,为什么?
我个人对客户端数据验证的偏好是第二种方法,它通知用户所有失败的约束。尽管我认为这取决于所涉及的业务逻辑,但我没有足够的信息对服务器端发表意见。
关于数据验证,我听说选项是“快速失败,早期失败”或“完全验证”。第一种方法在第一个验证错误上失败,而第二种方法建立一个失败列表并显示它。
我想知道在服务器端和客户端数据验证的上下文中。哪种方法适合什么情况,为什么?
我个人对客户端数据验证的偏好是第二种方法,它通知用户所有失败的约束。尽管我认为这取决于所涉及的业务逻辑,但我没有足够的信息对服务器端发表意见。
这令人困惑的部分原因是人们没有将正交性作为标准的一部分来讨论。'Fail-early' 很有用,以便错误在发生的地方而不是下游被捕获。但是对于正交故障,没有下游或多个下游。
例如,大多数用户表单都充满了许多独立的问题,例如用户名、密码、电子邮件。由于它们是独立的,请等到所有 3 个都到达,并立即描述所有错误。让用户经历三个提交-检查-投诉周期是荒谬的。
对于诸如无效输入或丢失数据等微不足道的错误,您希望为用户制作系统的方便程度取决于您。例如,如果有人将完整的数据电子表格导入系统并且第一行失败并且您说“第一行失败”,这可能会非常烦人。用户修复第一行,导入并收到“第二行失败”消息。想象一下有 65536 行。您已经知道您不会对数据做任何事情,但是您想让用户的生活更轻松吗?同样,这些是我正在讨论的微不足道的错误,当然您将设计一个在处理之前验证所有数据的系统。
对于更严重的错误,或者您没有预料到或者不仅仅是验证问题,请恢复为快速和困难的失败。