很长一段时间以来，我一直试图弄清楚用户输入的验证应该在 Spring MVC 应用程序中的什么位置进行。在许多在线博客和教程中，我基本上读到 Controller 应该验证用户输入，如果无效，则通过显示包含错误消息的页面来响应用户。然而，我目前对 Spring 和 Spring MVC 分层系统的理解是，Controller 是应用程序逻辑(服务层)和“Web 世界”之间的唯一浅层接口(interface)，允许从 Web 使用服务层。另外，据我所知，Spring MVC 确实只提供了在 Controller 中进行验证的合理工具。
如果现在验证发生在 Controller 中，如果稍后我想从“网络世界”中解开应用程序逻辑，则必须在新环境中重新实现验证逻辑(例如使用 Swing 的桌面应用程序)。在我看来，决定哪些操作在域对象上“有效”以及这些对象可能具有哪些“有效”状态的能力是服务层的核心部分，而不是应用程序的其他部分(例如 Controller )。
在这种情况下，为什么将输入验证逻辑放在 Controller 层而不是服务层是“好的做法”？
最佳答案
一种常见的方法是在两个地方都进行验证。但是如果你在谈论@Valid，根据我的经验，放在 Controller 级别会更好。
这也取决于我们在谈论什么样的验证逻辑。假设你有一个 bean:
@Data
public class MyBean {
@NotNull private UUID someId;
@NotEmpty private String someName;
}
在 Controller 级别使用 @Valid 注释此 bean 是有意义的，因此它甚至不会到达服务。将 @Valid 放在服务方法上没有任何好处，因为您为什么要进一步传播它，而您可以立即在 Controller 中决定它是否是那种有效的。
还有第二种类型的验证:业务逻辑验证。假设对于同一个 bean，someId 属性是 timeUUid，并且它的时间戳最多需要在某个事件发生后 2 天，否则，该 bean 应该被服务丢弃。
这似乎是一个业务逻辑验证案例，因为仅查看 bean，您将无法验证它，除非您对其应用一些逻辑。
由于这两种验证方法实际上验证的是不同的事物，很明显，您的每个 MVC 组件(模型、 View 和 Controller )都进行自己的验证，并且在不引入相互依赖的情况下验证的内容应该是合理的组件。
至于向用户显示错误，是的，Errors object 确实旨在用于 Controller 级别的 bean 验证，但是您可以设计一些过滤器来捕获任何级别的异常，然后为用户漂亮地格式化它。有很多方法，我不确定 Spring 是否规定任何一个都比另一个更好。
根据不同的解析机制(例如，jSTL 或 jackson 或其他)，您可能会倾向于以不同的方式处理验证。例如，传统的 jstl view resolver可以很好地与使用错误的装置一起使用，而 jackson resolver @ResponseBody 的组合可能会更好地工作还有一些过滤器可以捕获错误并将它们放入响应对象的预定义错误部分。
关于java - Controller 或服务层中的 Spring MVC 验证？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/21407840/