何时使用 Bean 验证与自定义验证框架？

Question

我正在验证我的数据访问对象类的字段。在一次尝试中，我开始向属性（@NotNull、@NotBlank、@Min、@Max 等）添加 Bean 验证注释。我还有更多注释 Jackson (JsonProperty (..)) 用于 swagger 库和文档（@Api (...)）。在我看来，这个类非常“脏”，有很多注释（每个属性至少有三个注释）。一个字段的示例：

@JsonProperty("ownName")
@Api(description="it is my own name" required=true)
@Valid
@NotNull
private SomeObject object; 

在另一次尝试中，我使用 SpringValidator接口执行了我自己的验证。如果使用自定义验证器，例如 Spring 接口，它似乎更清晰，并且还允许您自由地为不同情况生成多个验证器。此外，该类似乎没有过多的注释和验证独立于该类。示例Validator：

public class UserValidator implements Validator {

    @Override
    public boolean supports(Class<?> arg0) {
        return User.class.isAssignableFrom(arg0);
    }

    @Override
    public void validate(Object obj, Errors error) {
        User user = (User) obj;
        if(user.getPassword().length() < 10)
        {
            error.reject("Password must be lesser than 10");
        }

        //more validations....

    }
}

• 你什么时候会使用一个或另一个？
• 各自的优缺点是什么？

Answer 1

我认为这是一个品味和用例的问题。我同意有时感觉一个人最终会出现某种注释超载。

使用 Bean 验证的一些原因是它是一个标准。约束注释是标准化的，许多框架都与它集成，例如 JPA，以防您想添加另一个基于注释的框架;-)

使用 Spring 之类的东西会将您绑定到特定的库/框架。您的代码将不那么可移植。如果您当然从未见过将 Spring 抛在后面的场景，那么这可能无关紧要。

当然，您可以完全自己做一些事情，但在这种情况下，您需要将整个集成代码编写到例如 Spring、REST、JPA 等中。

编写通用验证框架也并非易事。有很多事情需要考虑。