验证多层应用程序的输入数据的最佳实践

同意Pangea，您肯定应该在客户端和服务端点进行验证。 我想补充一点，验证的概念是“快速失败”。您可以向每个层添加验证，以便用户或调用者可以立即获得有关调用失败的原因的反馈，而不是可能启动事务，进行复杂查询并执行写入以查找字段太短。 在客户端，您需要尽可能多的验证，这样您就不会浪费用户的时间，带宽和服务器端资源（在许多情况下会产生争用）。但是，您通常无法在客户端进行所有验证（例如，检查是否已经在注册时使用了这样的用户名），因此您希望选中此选项并在发布时立即返回正确的错误消息点击服务层。 在服务器层，您希望假设所有输入都有潜在危险和不正确（并且它们通常是时间）。我认为最好是更全面和积极地验证服务层上的输入，因为这是你的最后一道防线。如果你在客户端省略一两个验证，你只需要一个好的故障处理机制让用户知道什么是错的。如果您错过了服务端的某些内容并发生灾难，则可能意味着需要数小时或数天的调试并尝试恢复数据库备份。 还有一些检查在数据库级别完成，这些检查强制执行诸如引用完整性之类的事情。我通常会在尝试写入之前尝试尽可能多地检查它们，因为解释各种RDBMS的错误消息并尝试将它们转换回用户可理解的术语通常很难，如果不是不可能的话。     

如果您的应用程序提供了多个入口点（UI或系统到系统接口或批处理系统），那么您应该在所有这些边缘以及到达服务层之前清理（空检查，格式化检查，必需等）您的数据。但这并不意味着您需要复制验证逻辑。您可以使用允许集中验证的框架。一些示例验证框架可以在这篇文章中找到。 但是，业务验证应属于您的域层，并且应保留在域服务层或域对象中。 我不同意您应该在DAO中执行验证。 DAO应该负责CRUD操作。如果他们做得更多，那么你就会有漏洞。如果您必须批量处理东西，那么您应确保批处理通过服务层，以便您的批处理也经历相同的验证。     

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