在控制器或服务层中的Spring MVC中进行验证? [英] Validation in Spring MVC in Controllers or Service Layer?

问题描述

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

For quite some time I try to figure out where validation of user input should take place in a Spring MVC application. In many online blogs and tutorials I basically read that a controller should validate the users input and, if invalid, respond to the user by showing a page containing the error message. My current understanding of the Spring and Spring MVC layering system, however, is that a Controller is a only shallow interface between the application logic (service layer) and the "web world", allowing usage of the service layer from the web. Also, as far as I can see, Spring MVC does only provide reasonable tools for validation in a Controller.

如果现在验证是在Controller中进行的，如果以后要从网络世界"中取消应用程序逻辑，则必须在新环境(例如，使用Swing的桌面应用程序)中重新实现验证逻辑.我认为，决定哪些操作对域对象有效"以及这些对象可能具有的有效"状态的能力是服务层的核心部分，而不是应用程序其他部分的关注(例如，控制器).

If now validation takes place in a Controller, if at some later point I want to untie the application logic from the "web world", validation logic must be reimplemented in the new environment (e.g. a desktop application using Swing). In my opinion, the ability to decide which operations are "valid" on domain objects, and what "valid" states such objects may have, is core part of the service layer, and not the concern of some other part of the application (e.g. Controllers).

在这种情况下，为什么将输入验证逻辑放置在控制器层而不是服务层中是优良作法"?

In this context, why is it "good practice" to place input validation logic in the controller layer and not the service layer?

推荐答案

一种常见的方法是在两个地方都进行验证.但是，如果您在谈论@Valid，从我的经验来看，最好将其设置为Controllers级别.

A common approach is to do validation on both places. But if you are talking about @Valid, from my experience it is nicer to put on Controllers level.

这也取决于我们在谈论哪种验证逻辑.假设您有一个豆子:

It also depends what kind of validation logic we are talking about. Let's say you have a bean:

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

在控制器级别用@Valid对该bean进行注释是有意义的，因此它甚至无法到达服务.将@Valid放在service方法上没有任何好处，因为为什么您要进一步传播它，而又可以立即在控制器中确定它是否是这种有效方法呢.

It would make sense for this bean to be annotated with @Valid on the controller level so it doesn't even reach the service. There is no benefit to putting the @Valid on the service method, because why would you propagate it further while you can immediately in the controller decide if it is that kind of valid or not.

然后是第二种验证类型:业务逻辑验证.假设对于同一个bean，someId属性是一个timeUUid，并且它的时间戳记必须在发生某个事件后最多2天，否则，该bean应该被服务丢弃.

Then there is a second type of validation: business logic validation. Let's say for the same bean that the someId property is a timeUUid and its timestamp needs to be at most 2 days after some event occurred, in other case, the bean should be discarded by the service.

这似乎是一个业务逻辑验证案例，因为仅查看Bean，您将无法对其进行验证，除非您对其应用了一些逻辑.

That seems like a business logic validation case, because by just looking at the bean, you wouldn't be able to validate it, unless you apply some logic to it.

由于两种验证方法实际上都验证了不同的事物，因此很明显，您的每个MVC组件-模型，视图和控制器都进行了自己的验证，并且验证的内容应该合理，而不会引入对其他对象的依赖性组件.

Since both approaches to validation actually validate different things, it is obvious to see that each of your MVC components - Model, View and Controller, do their own validation and it should be reasonable about what it validates without introducing dependency to the other components.

关于向用户显示错误，是的，错误对象用于控制器级别的bean验证，但是您可以设计一些过滤器来捕获任何级别的异常，然后为用户设置漂亮的格式.有很多方法可以解决，而且我不确定Spring是否规定了任何一个比另一个要好.

As for showing the error to the user, yes, the Errors object is indeed intended to be used for bean validation at controller level, but you can design some filter that catches exceptions on any level and then pretty formats it for the user. There are many approaches to it, and I am not sure if Spring prescribes that any is better than the other.

取决于不同的解析机制(例如jstl或jackson或其他)，您可能会倾向于以不同的方式处理验证.例如，传统的 jstl视图解析器可以很好地使用使用错误的工具，而

Depending on different resolve mechanism (as in, for example, jstl or jackson or something else), you would probably be inclined to deal with validation in a different way. For example, a traditional jstl view resolver would nicely work with a contraption that uses Errors, while a jackson resolver would probably work nicer with a combination of @ResponseBody and some filter that catches errors and puts them in a predefined error part of the response object.

这篇关于在控制器或服务层中的Spring MVC中进行验证?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！