应用程序中进行验证的最佳位置在哪里?经验法则?

每个模块都应该进行自己的验证,永远不要相信调用代码给它的内容。这通常意味着验证应该在应用程序的每一层进行。您尤其不希望信任在客户端进行的任何验证,因为这可能会导致安全漏洞。已知在客户端上运行的代码会不时更改。

我不确定这是否是最好的方式,但我做事的方式是。。

• 使我的业务对象。
• 定义某种验证框架,以便业务对象可以返回其当前状态的错误列表,并使用单元测试对这些错误进行测试。
• 如果您使用的是linq to sql,请实现OnValidate()部分方法,并使其调用mybusinessobject.geterrors()。执行db.submitchanges()操作时会调用OnValidate,以便停止保存无效数据
• 然后客户端验证,如果你可以被纵火

这是scott guthrie在这里描述的一个框架: http://weblogs.asp.net/scottgu/archive/2008/09/02/asp-net-mvc-preview-5-and-form-posting-scenarios.aspx

根据经验,正如您所说,您应该尽早进行验证,但是在客户机-服务器应用程序中,尽快在服务器上验证数据以防止可能出现的安全问题非常重要。

我想你应该验证三次。

1. 在客户端中,服务器上有2个,服务器上有3个。在具有检查约束的数据库中。

在控制台应用程序中,您可以立即验证,因为您知道用户输入数据的顺序。

我喜欢在用户单击“确定”或“下一步”后进行验证—在他们离开屏幕之前,他们处于打开状态。修改过程中的验证很少起作用-用户必须能够退格,在输入字符串时插入字符串,并且复制/粘贴到字符串字段中有自己的问题。如果字符串在有效之前一直是红色的,这可能会有所帮助,但在更正之前,您仍然必须阻止继续。与离开文本框类似,在输入数据时出现消息框可能会引起不安。等到用户说一切都完成了,然后立即进行所有验证。

我喜欢 Timothy's picking up on MVC .

由于我们很少了解应用程序的性质,我想指出一些非常普遍的经验法则以及已经提供的好建议。

2. 用户不会丢失工作

3. 用户的活动永远不会处于错误输入无法轻易识别和简单收回的状态

6. 用户不会因为验证的方式和时间而在完成有用的工作时感到沮丧

这应该差不多就够了。

根据应用程序的进展情况,您可以在离开该页面/步骤之前进行验证(如果它类似于一个向导,您可以通过多个页面/步骤进行验证),也可以在用户离开该文本框/值后立即进行验证。另一个选项是在修改时进行验证。

关于一般最佳实践,这里有很多很好的答案。。。但您的问题指定了“MVC”,对此只有一个正确答案。

MVC=模型视图控制器

所有业务逻辑都在控制器中。那是 这个 答复

另一个提示:如果您可以在所有验证逻辑都可以解释的元信息中定义验证规则,那么到处验证就容易多了。然后,您只需要在一个地方定义规则,而不必担心客户端验证、服务器端验证和测试用例彼此不同步。