代码之家  ›  专栏  ›  技术社区  ›  devoured elysium

在哪里验证程序中的用户输入?

  •  2
  • devoured elysium  · 技术社区  · 14 年前

    比方说,我必须为一家小型诊所公司实施一个程序,允许其用户(即医生)安排咨询、记录客户的医疗历史等。因此,这可能是标准的三层应用程序:演示、控制器和数据层(将连接到一个数据库)。SE)。

    我看到3种可能性:

    1. 我的第一个想法是将验证代码放在域层中。但是我觉得我可能会尝试在类A上进行检查,然后在使用A的B上进行相同的检查,然后在使用B的C上进行检查,等等。另一方面,它是好的,因为单元测试验证逻辑很容易。

    2. 有第二种想法认为,验证用户输入的最佳位置是尽快,也就是说,可能在表示层(或在控制器中)。一般来说,这似乎是个好主意。如果在控制器上,也可能很容易进行单元测试。它还允许您切换视图或数据层,并且仍然拥有所有的权利。

    3. 尝试将尽可能多的验证逻辑放在数据库本身上。这似乎是个好主意,因为它强制要求没有数据损坏数据库。我看到的问题是,如果我想使用不同的数据存储库,那么对于新的存储库,我必须再次使用数据验证逻辑。例如,在域层使用这种逻辑就不会有这个问题。

    你通常如何处理这个问题?

    3 回复  |  直到 14 年前
        1
  •  9
  •   duffymo    14 年前

    正如您所注意到的,有多个地方可以验证数据。

    还有几种验证级别:

    1. 正确的格式和类型;所有必需的值都存在(例如,如果需要出生日期,请确保它出现并且是日期类型;如果是字符串,请确保它符合预期的格式,如“yyyy-mm-dd”)。
    2. 级别1加上“业务正确性”:完成的事务根据您的业务规则有效(例如,“出生日期必须至少早于今天18年”)。

    有一个学派认为你应该考虑所有这些因素:

    1. 对客户端进行验证,以确保为用户提供最佳体验。不要让他们等待到服务器的往返以发现问题。将一个javascript验证放在适当的位置,它将立即告诉他们级别1的有效性。
    2. 在服务器端再次验证,因为服务层前面可能没有用户界面。绑定并验证进入服务层的所有值。
    3. 作为服务层中事务的一部分执行所有级别2验证。从业务角度确保输入正确。
    4. 如果数据库由多个应用程序共享,请将业务逻辑放入约束、存储过程和触发器中,以确保数据完整性。

    我认为这不应该是“要么”的决定。

        2
  •  1
  •   Bernd    14 年前

    不要混淆“何时”和“何地”。

    “何时”应尽可能早,可能由预设层触发。

    “Where”应该靠近域逻辑。

    结合起来,例如,这可能意味着让表示层调用域逻辑提供的验证服务。

        3
  •  0
  •   Shiraz Bhaiji    14 年前

    您通常需要在以下几层进行验证:

    • 客户端层,以确保用户体验尽可能好。例如,避免输入10个字段,然后由于输入无效而必须重新开始。
    • 在服务层,由于您不能100%确定客户机已经处理了请求(可能有人直接向服务层发送了消息)。
    • 在服务层,因为有些东西无法在客户机上检查。

    好消息是,有些技术允许您一次性指定验证规则,它们将为客户机和服务器生成验证代码。见 http://weblogs.asp.net/scottgu/archive/2010/01/15/asp-net-mvc-2-model-validation.aspx 这对上述前两种情况有帮助。