Spring MVC在控制器或服务层中的验证？

Question

很长一段时间,我试图弄清楚应该在Spring MVC应用程序中进行用户输入的验证.在许多在线博客和教程中,我基本上读到控制器应验证用户输入,如果无效,则通过显示包含错误消息的页面来响应用户.然而,我目前对Spring和Spring MVC分层系统的理解是,Controller是应用程序逻辑(服务层)和"Web世界"之间唯一的浅层接口,允许从Web使用服务层.另外,据我所知,Spring MVC仅提供合理的Controller验证工具.

如果现在验证发生在Controller中,如果稍后我想解开"web world"中的应用程序逻辑,则必须在新环境中重新实现验证逻辑(例如使用Swing的桌面应用程序).在我看来,决定哪些操作在域对象上"有效"以及这些对象可能具有哪些"有效"状态的能力是服务层的核心部分,而不是应用程序的其他部分的关注(例如控制器).

在这种情况下,为什么将输入验证逻辑放在控制器层而不是服务层是"良好实践"？

Answer 1

一种常见的方法是在两个地方进行验证.但是,如果你在谈论@Valid,根据我的经验,将控制器级别提升是更好的.

它还取决于我们所讨论的验证逻辑.假设你有一个豆子:

@Data
public class MyBean {
    @NotNull private UUID someId;
    @NotEmpty private String someName; 
}

这个bean @Valid在控制器级别上进行注释是有意义的,因此它甚至无法到达服务.将@Valid服务方法放在服务方法上没有任何好处,因为为什么你可以进一步传播它,而你可以立即在控制器中决定它是否有效.

然后是第二种类型的验证:业务逻辑验证.假设对于同一个bean,someId属性是timeUUid,并且它的时间戳需要在某个事件发生后最多2天,在其他情况下,该bean应该被服务丢弃.

这看起来像是一个业务逻辑验证案例,因为只要查看bean,你就无法验证它,除非你对它应用一些逻辑.

由于两种验证方法实际上都验证了不同的东西,因此很明显可以看到每个MVC组件 - 模型,视图和控制器都进行自己的验证,并且在不对其他组件引入依赖性的情况下验证它的验证应该是合理的.

至于向用户显示错误,是的,Errors对象确实打算用于控制器级别的bean验证,但是您可以设计一些过滤器来捕获任何级别的异常,然后为用户进行相当格式化.它有很多方法,我不确定Spring是否规定任何方法都比另一方好.

根据不同的解析机制(例如,jstl或jackson或其他东西),您可能倾向于以不同的方式处理验证.例如,传统的jstl视图解析器很适合使用错误的装置,而杰克逊解析器可能会更好地使用@ResponseBody和一些捕获错误的过滤器并将它们放在响应对象的预定义错误部分中.