java中心控制器,关于java：控制器或服务层中Spring MVC中的验证？

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

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

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

jeejava.com/spring-service-layer-bean-validation/

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

这也取决于我们在谈论哪种验证逻辑。假设您有一个bean：

@Data

public class MyBean {

@NotNull private UUID someId;

@NotEmpty private String someName;

}

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

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

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

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

至于向用户显示错误，是的，Errors对象确实旨在用于控制器级别的bean验证，但是您可以设计一些过滤器来捕获任何级别的异常，然后为用户格式化。有很多方法可以解决，而且我不确定Spring是否规定任何方法都比其他方法更好。

根据不同的解析机制(例如jstl或jackson或其他)，您可能倾向于以不同的方式处理验证。例如，传统的jstl视图解析器可以很好地与使用Errors的组件一起工作，而jackson解析器可能可以结合使用@ResponseBody和一些捕获错误并将其放入响应对象的预定义错误部分的过滤器来更好地工作。

@xSNRG大多数情况下，没有理由在两个验证范围之间进行同步。控制器层应该简要检查它可以验证的所有bean属性，如果所有的属性都似乎有效，则将其传递给服务。然后，服务应进行自己的业务验证，并将其传递给模型(模型应具有自己的域约束和验证工具)。如果您不紧密耦合这些层，则将不需要在它们之间进行任何同步，而只需维护每个层即可。

它在您的答案中并不十分清楚，但是您是否建议不应将javax.validation用于业务逻辑验证？如果可以的话，从我目前的理解来看，您似乎可以用两个单独的自定义验证器将问题分开，如果您正在执行的两种验证类型如此不同以至于它们应该分开，那么它们就可以验证相同的对象/类。

@CopyandPaste我在回答中提到了两种类型：验证的"原始正确性"：数据实际上有任何意义)：例如，必填字段是否为必填字段，整数为正数等，然后是业务验证，这可能比简单地检查几个属性是否为空要复杂得多，例如，您是否有能力处理订单，这甚至可能涉及数据库调用，而您可能会从"原始"验证中分离出某些东西并放入验证服务中，或者某种东西。 javax。*比其他类型更适合"原始"，但不是100％规则。

在我们以前的项目之一中，我们具有逻辑非常复杂的庞大形式，这意味着需要大量验证代码。因此，我们使用了第三种解决方案。对于每个控制器，我们都会自动连接一个助手类。

例：

myview MyController

^

|

MyHelper

Controllers处理了视图解析。

Services处理了从dto-s到视图的模型对象之间的映射，反之亦然，

DAO-s处理数据库事务，并且

Helpers处理了包括验证在内的所有其他内容。

如果现在有人希望将前端从Web更改为其他东西，那会容易得多，同时，我们也不会过度夸大服务实现类。