使用Spring MVC向用户显示服务级别验证错误的良好实践

Question

在使用Spring MVC验证器执行了“浅层”用户输入验证后，是否有一些好的做法可以使用Spring MVC来显示服务层验证错误？例如，使用以下代码：

@Autowired
private UserService userService;

@RequestMapping(value = "user/new", method = RequestMethod.POST)
public String createNewUser(@ModelAttribute("userForm") UserForm userForm, BindingResult result, Model model){
    UserFormValidator validator = new UserFormValidator(); //extending org.springframework.validation.Validator
    validator.validate(userForm, result);

    if(result.hasErrors()){
        model.addAttribute("userForm", userForm);
        return "user/new";
    }

    // here, for example, the user already might exist
    userService.createUser(userForm.getName(), userForm.getPassword());

    return "redirect:user/home";
} 

虽然将此代码作为示例看起来微不足道，但当服务层的验证是一项复杂的任务时，对我来说，这似乎是一个微妙的故事。尽管这是一个荒谬的场景，UserService可能会创建一个用户列表，如果其中一个已经存在，那么必须以某种方式通知视图层其中哪些是无效的（例如已经存在）。

尽可能容易。有什么建议吗？

Answer 1

选择通常是异常而不是错误代码（或响应代码），但最佳实践（至少是Bloch的做法）是只在特殊情况下使用异常，这在这种情况下使异常失效，因为用户选择现有用户名并非闻所未闻。

服务调用中的问题是，假设createuser是一个命令命令，没有返回值。你应该把它看作是“尝试创建一个用户，然后给我一个结果”。结果可能是

• 整数代码（可怕的想法）
• 共享结果枚举中的常量（由于可维护性，这仍然是个坏主意）
• 来自更具体的常数，如UserOperationResult枚举（更好的主意，因为在创建新用户和尝试修改用户时，您可能希望返回User_alReady_Exists)
• 完全自定义此调用的UserCreationResult对象（这不是一个好主意，因为您将得到大量此类调用）
• 一个result 或UserOperationResult 包装器对象，它将响应代码常量（分别为ResultCode或UserOperationResultCode)和返回值T或通配符？（如果没有返回值）结合在一起...只是要注意那些不需要包装器的切入点之类的东西）

未检查异常的美妙之处在于，它们避免了所有这些废话，但它们也有自己的一系列问题。我个人会坚持最后一个选择，而且在过去运气不错。