项目中常用的后端数据校验框架有哪些？HibernateValidator只能校验对象，对于基本数据类型的参数用哪种方式校验好？

Z时代
2024-01-10
分类：IT

如下方法中，只能对UserDto对象进行校验，但对于name参数无法进行校验，大家常用什么方式对参数进行校验呢？

@ResponseBody
@RequestMapping(value = "/validate", method = RequestMethod.GET)
public ResponseEntity<String> validate(@Valid @NotBlank String name, @Valid UserDto userDto, BindingResult result){
}

还有，常用是在controller层进行校验呢？还是在service层比较好？接收参数的对象命名使用dto好还是vo好？如果使用hibernatevalidator会不会导致接收参数的小对象激增，那么命名上要怎么管理？

大家有什么好的实践经验，欢迎讨论

回答：

我尝试修改了你的方法，将它改成下面这样：

@ResponseBody
@RequestMapping(value = "/validate", method = RequestMethod.GET)
public ResponseEntity<String> validate(@RequestParam String name, @Valid UserDto userDto, BindingResult result){
}

这个方法会校验name参数不为空。

另外，针对你的几个问题，做出简单回答。

Q1.常用是在controller层进行校验呢？还是在service层比较好？
A1：校验通常放在Controller，可以使用Spring MVC配合JSR 303做请求参数校验。Service只负责处理业务逻辑。

Q2.接收参数的对象命名使用dto好还是vo好？
A2：这要取决于你的接口设计，如果接口接收的参数是一个复合对象，这个对象由多个DTO组成，可以考虑用VO；如果参数比较简单，可以直接用DTO。考虑下面的代码片段：

public class UserVO {
    private UserDTO user;
    private RoleDTO role;
    ...}

public class UserDTO {
    private String username;
    private String password;
    ...}

以上个人想法，仅供参考。另外，我找到了这篇文章，希望可以帮到你：

Q3.如果使用hibernatevalidator会不会导致接收参数的小对象激增，那么命名上要怎么管理？
A3：HibernateValidator本身是JSR303规范的实现，Spring对其做了较好的封装，使用起来比较方便。如果你担心方法参数过多，可以考虑合并成一个对象。（如果一个方法中超过5个参数，考虑用对象替代）