什么时候使用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; 

在另一次尝试中，我使用spring的validator接口执行了自己的验证。如果使用自定义验证器，如spring接口，它似乎更干净，并且允许您自由地为不同的情况生成多个验证器。而且，类似乎不会被注释重载，并且验证是独立于类的。验证程序示例：

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等。

此外，编写一个通用的验证框架也不是一件容易的事。有很多事情要考虑。