在我们的应用程序中，我们有不同的层。服务层、DAO 层和操作（struts 应用程序）。
数据从一层传递到另一层。
理想情况下我们应该把输入验证放在哪里？
比如说，用户 ID、电话号码来自 UI，它们是强制性的。所以我们已经在客户端进行验证。
现在，根据我的观点，这就是你所需要的。没有其他地方应该验证它。
但是我的一位同事争辩说，如果客户直接提出要求怎么办。所以我们还需要添加Actions。
现在，在 Dao 中，同样的方法也被用于其他一些操作，并且没有验证，
或者，说服务层，它可能被暴露为，比如 web 服务，所以你也有验证。
所以本质上，他是在建议..我们到处都有验证。这对我来说没有意义。它的跨层重复。
什么是理想的方法？说验证可能是简单的空检查或一些复杂的验证。
同意 Pangea，您绝对应该在客户端和服务端点中进行验证。
我要补充一点，验证的概念是“快速失败”。您向每一层添加验证，以便用户或调用者能够立即获得关于调用失败原因的反馈，而不是潜在地启动事务、进行复杂的查询和只写发现字段太短。
在客户端，您需要尽可能多的验证，这样您就不会浪费用户的时间、带宽和服务器端资源（在许多情况下存在争用）。但是，您通常无法在客户端进行所有验证（例如，检查注册时是否已经使用了这样的用户名），因此您希望检查并尽快返回正确的错误消息击中服务层。
在服务器层，您希望假设所有输入都具有潜在危险和不正确（而且它们经常会如此）。实际上，我认为在验证服务层上的输入时更加全面和积极会更好，因为这是您的最后一道防线。如果你在客户端遗漏了一两个验证，你只需要一个很好的故障处理机制来让用户知道哪里出了问题。如果您错过了服务端的某些内容并发生了灾难，则可能意味着需要数小时或数天的调试和尝试恢复数据库备份。
在数据库级别也进行了一些检查，这些检查会强制执行诸如参照完整性之类的事情。我通常会在尝试写入之前尽可能多地检查它们，因为解释各种 RDBMS 的错误消息并尝试将它们转换回用户可以理解的术语通常很困难，如果不是不可能的话。
如果您的应用程序提供了多个入口点（UI 或系统到系统接口或批处理系统），那么您应该在所有这些边缘和到达服务层之前清理（空检查、格式检查、必需性等）您的数据。但这并不意味着您需要复制您的验证逻辑。您可以使用允许您集中验证的框架。在这篇文章中可以找到一些示例验证框架。
但是，有些业务验证应该属于您的领域层，它们应该保留在您的领域服务层或领域对象中。
我不同意您应该在 DAO 中执行验证。DAO 应该只负责 CRUD 操作。如果他们做得更多，那么您就有泄漏层。如果您必须批量处理东西，那么您应该确保批次通过服务层，以便您的批次也经过相同的验证。
我可以添加到对话中的一条智慧是，永远不要相信客户。无论您的客户端是 HTML、Flash/Flex 还是其他格式，都有可能有人会破解它并尝试做一些您不希望他们做的事情。这里的后续行动是，如果有人可能会破解它，我们作为软件工程师必须假设它会被破解，所以虽然前端检查很好，并且可以帮助您的应用程序可用性，您必须在后端验证所有输入，即使这会导致重复检查。