java - 验证，它位于模式方面

Question

假设我们有 MVC 。我们的 C 很聪明，只充当路由器，我们还有业务层调用我们的持久层 - DAO。

我们将验证放在哪一部分。我不是在谈论放置在模型或 DTO 类字段上的基于注释的验证，而是一些更复杂的东西，比如当你创建一个 validator 类本身时。您将如何在正式图表中说明这一点。我假设它驻留在业务逻辑中。但同时在 Spring MVC 中验证更多地面向 Controller 。

请分享您认为合适的内容。

Answer 1

我感觉验证问题也是分层结构的，例如表示、业务和数据库。

层的名称首先对验证规则没有任何意义。 (这仅意味着这些是检查验证规则的层。)

你可能应该注意到一个重要的事情，我主要开发 web 应用程序，而这个“规则”是针对此类应用程序的，而不是针对批处理作业等其他东西

让我们从下到上:

数据库层验证规则。这些主要是“不为空”(对于字段和关系)。在这一层中存在所有验证约束(并由数据库强制执行)，这些约束是实现本身所必需的。这意味着如果存在验证违规，应用程序将崩溃。 (这并不意味着业务逻辑可能会计算出错误，它实际上意味着应用程序根本不返回(有用的)结果)。在数据库层验证规则中需要理解的一件重要事情是，该层中的规则违规意味着错误。所以这些规则的目的不是检查，它的目的是确保不会持续存在严重的验证违规，并且该应用程序不会在每次加载数据库记录时崩溃! -- 所以违反这个约束会直接导致无法解决的异常。因为原因是错误，不可能修复一条错误的数据库记录。

业务层验证这种验证规则存在于业务层，主要存在于服务功能中。诸如“用户名必须是唯一的”之类的东西。违反此规则不会导致程序本身崩溃，但可能会导致错误的业务结果。第二个重要的事情是，业务层验证规则也可以由数据库强制执行。但是，应该缓存和处理违规异常，而不是 Unresolved 异常。业务层验证违规不是错误，它们只是错误的输入。

表示层验证此验证规则是没有任何意义的规则。大多数情况下，这些都是一些愚蠢的业务规则，每天都在变化，并且不会影响业务结果。这些规则如下:“对堆栈溢出问题的评论必须至少有 10 个字符长”。我只在表示层(当然是在服务器端)检查这些规则。

当然，在表示层的输入表单中也应该检查业务或数据库层的约束(只要有可能而不需要太多工作)。因此，例如，如果有一个字段不能为空，那么也应该在表示层的输入表单处理程序中检查它。