假设我们有MVC。我们的C很聪明，只作为路由器，我们还有业务层调用我们的持久层 - DAO。
我们在哪个部分进行验证。我不是在讨论基于注释的验证，它放在模型或DTO类的字段上，而是更复杂，就像创建验证器类本身一样。你会如何在正式图表中说明这一点。我假设它存在于业务逻辑中。但同时在Spring中，MVC验证更多地面向控制器。
请分享您认为合适的内容。
答案 0 :(得分：3)
我觉得验证问题也是分层结构，如演示文稿，业务和数据库。
层的名称首先对验证规则没有任何意义。 （这意味着只有这些是检查验证规则的层。）
您可能会注意到一件重要的事情，我主要开发Web应用程序，这个“规则”适用于此类应用程序，但不适用于其他事项，如批处理作业
让我们自下而上：
数据库层验证规则。 这些主要是“非空”（对于字段和关系）。在该层中，所有验证约束都存在（并且由数据库强制执行），这些约束对于实现本身是必须的。这意味着如果存在验证违规，则应用程序崩溃。 （这并不意味着业务逻辑可能会计算错误，这实际上意味着应用程序根本不返回（有用）结果）。在数据库层验证规则中要理解的一件重要事情是，此层中的规则违规意味着错误。因此，这些规则的目的不是检查，其目的是确保不会持久存在任何关键验证违规，并且每次加载数据库记录时应用程序都不会崩溃！ - 因此违反此约束将直接导致未解决的异常。因为原因是一个错误，并且无法修复错误的数据库记录。
业务层验证 此验证规则存在于业务层中，主要存在于服务功能中。像“用户名必须是唯一的”之类的东西。违反此规则不会导致程序本身崩溃，但可能导致错误的业务结果。第二个重要的是，业务层验证规则也可以由数据库强制执行。但是，应该缓存和处理违规异常，而不是未解决的异常。而业务层验证违规不是错误，它们只是错误的输入。
表示层验证 此验证规则是没有任何意义的规则。这些是一些愚蠢的业务规则，每天都在变化，而不会影响业务成果。这些规则如下：“对堆栈溢出问题的注释必须至少为10个字符”。 我只在表示层检查这些规则（当然是在服务器端）。
当然，业务或数据库层约束应该（只要可能没有太多工作）在表示层中的输入表单中进行检查。因此，例如，如果某个字段必须不为null，那么也应该在表示层的输入表单处理程序中检查它。