Bean検証とカスタマイズ検証フレームワークのどちらを使用するのですか？

Question

私は自分のデータアクセスオブジェクトクラスのフィールドを検証しています。 1つの試みとして、プロパティ（@NotNull、@NotBlank、@Min、@Maxなど）にBean検証アノテーションを追加し始めました。私はまた、より冗長なライブラリとドキュメンテーション（@Api（...））のために、より多くの注釈Jackson（JsonProperty（..））を持っています。私の意見では、クラスは多くの注釈（各プロパティは少なくとも3つの注釈を持つ）で非常に "汚い"でした。一つのフィールドの例：別の試みで

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

は、私は春Validatorインターフェースで自分の検証を行ってきました。 Spring Interfaceのようなカスタムバリデーターを使用するときれいに見えますが、状況に応じて複数のバリデータを自由に生成することもできます。また、クラスはアノテーションでオーバーロードされていないようで、バリデーションはクラスとは独立しています。 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.... 

    } 
} 

• 使用すると、1つまたは別のものを使うのでしょうか？
• それぞれの長所と短所は何ですか？

Answer 1

味や使い方の問題だと思います。私は時にはある種の注釈過負荷で終わると感じることに同意します。

Bean検証を使用するいくつかの理由は、標準であるということです。制約の注釈は標準化されており、多くのフレームワークがそのフレームワークと統合されています。たとえば、別の注釈ベースのフレームワークを追加する場合はJPAなどです。

Springのようなものを使用すると、特定のライブラリ/フレームワークにバインドできます。あなたのコードは移植性が低くなります。もちろん、Springを後にしておくシナリオが決して見えない場合、これは重要ではないかもしれません。

あなたは何かが自宅全く成長しない可能性がありますが、この場合には、あなたが例の春、REST、JPAなど

のために全体の統合コードを記述する必要があります。もちろん、

また、汎用の検証フレームワークを書くことではありません簡単。考えなければならないことはたくさんあります。