在webapp(后端)中,您在哪里进行验证?

我通常将表单验证保存在服务层中,而不是对象本身。我这样做并不是因为我不同意将对象完全封装,而是因为它符合我在网站上选择用于处理表单提交的方法/设计模式。

我认为像transfer这样的框架鼓励您将对象验证保持在像引擎/框架这样的对象中 Alegad's Validat 旨在保持验证不受影响。我不认为这两种方法都是错误的,这实际上只是您喜欢什么(以及什么适合应用程序)的问题。

然而,在这3个选项中,选项2忽略了对具有预期结果的情况使用异常处理。通过使用validate方法(无论是在对象上还是在服务中),您可以更优雅地控制错误的验证情况,而不是捕获异常并被动地将其冒泡(捕获并返回包含失败信息的结构)或显式地(rethrow等)。

您在每个阶段都进行验证,但原因略有不同。

您可以验证用户何时设置值,以便立即向用户提供有关输入是否有效的反馈。该验证只应用于增强用户体验。您可以在用户键入时验证是否合适,但请确保不要阻止用户输入无效的部分输入,因为可能会有更多输入,您不希望验证妨碍您的工作。

您可以在用户提交表单之前进行验证,以确保提交的有效性,而不会产生到服务器的完整往返的时间成本。这主要是针对那些在用户输入期间没有或无法验证的内容,它可能涉及到与服务器的一些通信,例如,在不重新加载页面的情况下,检查用户名是否可用。这个阶段也主要是为了用户的利益。无论是在输入期间还是在提交时验证每个项目,都取决于您自己,并且应该取决于哪个项目提供了更好的用户体验,并且更适合用户的心理模型。

最后,当返回到服务器时,您需要验证所有内容,因为您不能信任浏览器。此验证主要用于安全性。您永远不能假设来自您的客户机的任何数据都是干净的,因为它可能不是来自您的客户机。它可能来自一个敌对的代理人,他在模仿你的客户。因此,无论是否在客户机中验证,都要完全验证所有可能的漏洞和其他无效条件。

希望有帮助。

首先,我给JBorque加1。

我想补充一点,输入类型验证是非常重复的,例如

用户界面:不允许名称超过30个字符 biz:如果名称超过30个字符,则引发异常/创建中断规则 数据库:使名称列宽30个字符 单元测试:测试名称<30,>30,正好30个字符长

这是代码生成的一个很好的候选者。如果30突然变为40,而您正在使用代码生成,那么进行更改就和重新运行代码生成器一样简单(并为任何生产数据创建DB升级脚本)。

我过去使用UML建模工具来捕获C中的输入规则和部分类,以将从UML模型生成的代码与我自己手工编写的代码分开。同样的概念可以很容易地应用到许多开发环境中。

+1也适用于JBourqu。不错的答案。 在任何地方都可以避免不合理的性能成本。我经常验证后端中ARN不直接公开的函数的输入,以防其他代码使用意外的值调用它们或混合参数顺序。