【问题标题】:Where is the best place in an app to do validation? Rules of thumb?应用程序中进行验证的最佳位置在哪里?经验法则?
【发布时间】:2008-11-30 15:15:27
【问题描述】:

我正在为一个班级项目制作一个 C# 应用程序。我想确保一个字符串具有三个值之一。通常,在 Web 应用程序中,我会在客户端使用 javascript 进行验证。但是,这目前是一个控制台应用程序。我知道我应该尽早进行验证,但有哪些好的验证经验法则?

【问题讨论】:

    标签: c# validation model-view-controller


    【解决方案1】:

    每个模块都应该进行自己的验证,并且永远不要相信调用代码给它的东西。这通常意味着验证应该发生在应用程序的每一层。您尤其不想相信任何验证发生在客户端,因为这会导致安全漏洞。众所周知,在客户端上运行的代码会不时更改。

    【讨论】:

      【解决方案2】:

      如果您正在使用 MVC,那么您很可能正在使用 TDD 从头开始​​工作。

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

      • 制作我的业务对象。
      • 定义某种验证框架,以便业务对象可以返回有关其当前状态的错误列表并使用单元测试对其进行测试。
      • 如果您使用 linq to sql,请实现部分方法 OnValidate() 并使其调用您的 mybusinessobject.geterrors()。当您执行 db.submitchanges() 时会调用 OnValidate,这样您就可以停止保存无效数据
      • 现在,在您的控制器中,当有人创建或编辑新业务对象时,使用您从用户那里获得的任何数据创建对象 - 然后调用您的 geterrors() 方法并执行任何操作
      • 如果可以的话,那就进行客户端验证

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

      我喜欢它,这意味着您可以定义一次业务规则并在不同的层上重复使用它们,这意味着您在更新内容时不太可能在特定区域错过它们

      【讨论】:

        【解决方案3】:

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

        【讨论】:

        • 正是...客户端的冗余验证可以避免验证往返,但服务器必须负责所有验证,以防止来自其他来源的未经验证的命中。
        【解决方案4】:

        我认为你应该验证三遍。

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

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

        【讨论】:

          【解决方案5】:

          我喜欢在用户单击“确定”或“下一步”之后进行验证——在他们离开他们所在的屏幕之前。在修改期间进行验证很少起作用 - 用户必须能够退格,在输入字符串时插入字符串,并且复制/粘贴到字符串字段有它自己的问题。如果字符串在有效之前一直是红色的,这可能会有所帮助,但在纠正之前,您仍然必须阻止继续进行。同样,对于离开文本框,在输入数据时显示消息框可能会令人不快。等到用户说一切都完成了,然后立即进行所有验证。

          【讨论】:

            【解决方案6】:

            我喜欢Timothy's picking up on MVC

            由于我们对应用程序的性质知之甚少,我想指出一些非常一般的经验法则以及已经提供的良好建议。

            以某种方式验证

            1. 没有对无效输入执行不可逆的操作

            2. 用户不会丢失工作

            3. 用户的 Activity 永远不会处于无法轻松识别错误输入并简单撤回的状态

            4. 应用程序不会失败或崩溃

            5. 由于应用程序处理无效数据而导致(或看到)任何(共享)持久材料处于不良状态

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

            这应该差不多涵盖了它。

            【讨论】:

              【解决方案7】:

              根据应用程序的进展情况,您可以在离开该页面/步骤之前进行验证(如果它像一个向导,您可以逐步完成多个页面/步骤),或者您可以在用户离开该文本框后立即验证它/价值。另一种选择是在修改时进行验证。

              【讨论】:

                【解决方案8】:

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

                编辑:你的“问题”没有说 MVC,但你的标签说了。

                MVC = 模型视图控制器

                所有业务逻辑都在 Controller 中。这就是答案。

                这篇文章中的其他答案是很好的提示,例如“不要信任客户端验证”......和“到处验证”。

                【讨论】:

                  【解决方案9】:

                  另一个提示:如果您可以在所有验证逻辑都可以解释的元信息中定义验证规则,那么在任何地方进行验证都会容易得多。那么您只需要在一个地方定义规则,您就不必担心您的客户端验证、服务器端验证和测试用例之间会不同步。

                  【讨论】:

                    猜你喜欢
                    • 1970-01-01
                    • 1970-01-01
                    • 1970-01-01
                    • 2023-03-21
                    • 2021-09-20
                    • 1970-01-01
                    • 1970-01-01
                    • 1970-01-01
                    • 1970-01-01
                    相关资源
                    最近更新 更多