代码之家  ›  专栏  ›  技术社区  ›  Erik Funkenbusch

如何管理复杂的数据输入验证

  •  3
  • Erik Funkenbusch  · 技术社区  · 14 年前

    当我开发ASP.NET Web表单应用程序时,我觉得我正在与当前的情况作斗争。我经常遇到同样的问题,虽然我最终找到了一些解决方法,但我从来没有对结果完全满意。

    下面是一个典型问题的例子:

    设计需要一个网格或类似网格的结果集。这个结果集是从数据库中提取的,但是,每行上都有其他控件,这些控件不是数据绑定的,但是它们的内容用于将数据插入到其他记录中。

    一个很好的例子是显示产品列表,然后根据输入到数量字段中的值和每个产品选择的选项将所选产品添加到购物车中。加入你必须允许多行同时添加到购物车的混合,它开始变得更加复杂。

    让我们再加一个你不能同时选择某些产品(互斥)的组合,你只能选择一种产品的某个数量,而不能选择另一种,当用户选择他们的产品时,价格可能会发生变化,你可以根据购买的数量(每个项目和整个订单)获得每个项目的总折扣,你可以使用的是信用额度,不能超过信用额度,也不能购买比您的账户或您的账户代表性的产品中设定的任意金额更多的某一特定项目(请确定政府限制您购买的处方药数量),等等。等。。等。。

    一个简单的网格加上一个购物车就变成了一堆毫无希望的业务逻辑,这当然需要验证并通知用户他们的选择中的各种错误。

    如何处理ASP.NET中非常复杂的数据输入方案?你是如何开始设计一个软件来完成这一切的?

    编辑:

    请不要建议更改接口,因为接口不是问题所在。用户对它很满意,他们要求它以它的方式运行。我正在寻找如何设计和解决实现它的问题的帮助。

    2 回复  |  直到 14 年前
        1
  •  1
  •   Jason Berkan whiteproud    14 年前

    不要在代码中放置除基本验证之外的任何东西。代码隐藏应该只获取用户输入的内容,构建业务对象(或业务对象集合),并让这些业务对象自己进行验证。

    每个业务规则应该是对业务对象的单个函数调用,它只处理一个规则,而不处理其他任何规则。然后你只需一个接一个地给他们打电话,并跟踪哪些人通过了,哪些人失败了。

    当验证失败时,业务对象可以提供足够的代码隐藏信息,以便显示正确的错误并突出显示有错误的字段。

        2
  •  1
  •   AUSteve    14 年前

    需要考虑的一些选项:

    • 分离验证逻辑,以便从客户端和服务器端代码调用它(启用下一点)。
    • 使用Ajax执行服务器端验证,并在用户执行各种任务时提供即时反馈,即增加数量。
    • 在执行任何操作之前和之后,向用户提供丰富而清晰的说明/反馈。之前:警告产品X不能与产品Y一起购买(特别是如果Y已经在购物车中)。之后:准确解释问题并提出纠正方法,例如“为什么不删除产品Y?”)
    • 优雅地失败,即如果只有一个产品未通过验证,则确保添加所有其他产品。
    • 简化输入过程,例如一次只允许将一个产品添加到购物车。

    最后一点很重要。一个复杂的数据输入过程可能会在用户开始之前将其混淆,并使试图理解众多验证错误变得困难。这甚至在你开始编码验证逻辑之前。