【问题标题】:Best practice for validating input data for multi-tier application [closed]验证多层应用程序的输入数据的最佳实践 [关闭]
【发布时间】:2011-01-31 07:28:36
【问题描述】:

在我们的应用程序中,我们有不同的层。服务层、DAO 层和操作(struts 应用程序)。

数据从一层传递到另一层。

理想情况下我们应该把输入验证放在哪里?

说,用户 ID,电话号码来自 UI,它们是强制性的。所以我们已经在客户端进行验证。

现在,根据我的意见,这就是你所需要的。没有其他地方应该验证它。

但我的一位同事争辩说,如果客户直接提出请求怎么办。所以我们还需要添加Actions。

现在,在 Dao 中,同样的方法也用于其他一些操作,但没有验证,

或者,说服务层,它可能被暴露为,比如网络服务,所以你也有验证。

所以本质上,他是在建议..我们到处都有验证。这对我来说没有意义。跨层重复。

什么是理想的方法?说验证可能是简单的空检查或一些复杂的验证。

【问题讨论】:

  • 感谢大家的回复。我的问题可能是编程级别。 (可能是我混合了两件事)。让我详细说明。假设有 ProcessAction、ProcessService 和 ProcessDao。他们都有 createProcess(Str p1, p2, p3...pn) 现在,假设我正在执行 null 检查以确保所有参数都不为 null。现在,对所有 3 个进程执行 null check kin 有什么意义? (可能这个例子有助于我想问的问题)@Pangea 验证框架将一直工作到 Actions,我如何在服务和 dao 层使用? (如果我遗漏了什么,请纠正我)

标签: java design-patterns multi-tier


【解决方案1】:

同意 Pangea,您绝对应该在客户端和服务端点中进行验证。

我要补充一点,验证的概念是“快速失败”。您向每一层添加验证,以便用户或调用者能够立即获得关于调用失败原因的反馈,而不是潜在地启动事务、进行复杂查询和仅写入以发现字段太短。

在客户端,您希望进行尽可能多的验证,以免浪费用户的时间、带宽和服务器端资源(在许多情况下存在争用)。但是,您通常无法在客户端进行所有验证(例如,检查注册时是否已经使用了这样的用户名),因此您希望检查并尽快返回正确的错误消息击中服务层。

在服务器层,您希望假设所有输入都具有潜在危险和不正确(而且通常情况下)。实际上,我认为在验证服务层上的输入时更加全面和积极会更好,因为这是您的最后一道防线。如果你在客户端遗漏了一两个验证,你只需要一个很好的故障处理机制来让用户知道哪里出了问题。如果您错过了服务端的某些内容并发生了灾难,这可能意味着需要数小时或数天的时间进行调试并尝试恢复数据库备份。

在数据库级别也进行了一些检查,以强制执行诸如参照完整性之类的事情。我通常会在尝试写入之前尽可能多地检查它们,因为解释各种 RDBMS 的错误消息并尝试将它们转换回用户可以理解的术语通常很困难,如果不是不可能的话。

【讨论】:

    【解决方案2】:

    如果您的应用程序提供多个入口点(UI 或系统到系统接口或批处理系统),那么您应该清理(空值检查、格式检查、必要性等)所有这些数据在它到达服务层之前。 但这并不意味着您需要复制您的验证逻辑。您可以使用允许您集中验证的框架。在post 中可以找到一些示例验证框架。

    但是,有些业务验证应该属于您的领域层,它们应该保留在您的领域服务层或领域对象中。

    我不同意您应该在 DAO 中执行验证。 DAO 应该只负责 CRUD 操作。如果他们做得更多,那么您就有泄漏层。如果您必须批量处理东西,那么您应该确保批次通过服务层,以便您的批次也经过相同的验证。

    【讨论】:

      【解决方案3】:

      我可以添加到对话中的一条智慧是,永远不要相信客户。无论您的客户端是 HTML、Flash/Flex 还是其他格式,都有可能有人会破解它并尝试做一些您不希望他们做的事情。这里的后续是,如果有人可能会破解它,我们作为软件工程师必须假设它会被破解,所以虽然前端检查很好,并且可以帮助您的应用程序可用性,您必须在后端验证所有输入,即使这会导致重复检查。

      【讨论】:

        猜你喜欢
        • 2012-05-09
        • 2020-05-22
        • 1970-01-01
        • 1970-01-01
        • 2016-01-09
        • 1970-01-01
        • 1970-01-01
        • 2014-04-11
        • 1970-01-01
        相关资源
        最近更新 更多