DDDオブジェクトのJSR 303 Bean検証とマニュアル（Apache Commons経由）を混在させる

Question

私たちのホームプロジェクトの多くのドメインオブジェクトはフィールドの検証が必要で、この目的のためにcommons-langを使用しています。たとえば：

public class Position { 
    private static final int LATITUDE_AMPLITUDE = 90; 
    private static final int LONGITUDE_AMPLITUDE = 180; 

    private Float latitude; 
    private Float longitude; 

    public Position(float latitude, float longitude) { 
     Validate.inclusiveBetween(-LATITUDE_AMPLITUDE, LATITUDE_AMPLITUDE, latitude, 
       "Latitude must be +- " + LATITUDE_AMPLITUDE); 
     Validate.inclusiveBetween(-LONGITUDE_AMPLITUDE, LONGITUDE_AMPLITUDE, longitude, 
       "Longtitude must be +- " + LATITUDE_AMPLITUDE); 

     this.latitude = latitude; 
     this.longitude = longitude; 
    } 
} 

我々はそれを結合ドメインは、インフラストラクチャとオブジェクトおよび検証を起動します外部からの介入を必要とするため、JSR 303を使用しないことを決めました。

しかし、RESTエンドポイントの実装を開始したとき、jsonコンバーターはクラスコンストラクターを使用せず、Reflectionを介して値を注入するため、検証の問題に直面しました。

JSR303とJerseyの@Validアノテーションを使用してオブジェクトを検証するのは非常に簡単ですが、JSR303でドメインオブジェクトに注釈を付ける必要があります。

1. JSR303検証のみを使用してください。 Imho、それは悪い選択です。これらのオブジェクトで動作するビジネスレイヤーには、JSR303検証トリガーという複雑な（より複雑なものはありません））のない検証されたオブジェクトも必要です。
2. JSR303 +手動検証を使用してください。アプリケーション層とビジネス層の両方を満足させますが、JSR303の依存関係とアノテーションのためにドメインオブジェクトを太ってしまいます。

あなたはこれについてどう思いますか？ JSR303とマニュアルバリデーションの両方を混ぜるのは良い方法ですか？

Answer 1

両方のモデルで広範な作業を行っていますが、私は個人的にはJSR 303 Beanの検証がより多くの喜びを感じています。これは私が純粋に豆の検証アノテーションを使用していることを意味し、手動の検証コードはありません。

Bean検証アノテーションは、検証ロジックをドメインエンティティ自体から切り離します。私はこれが良いことだと思うのは、あなたのドメインエンティティの定型コードを減らし、読みやすく保守性に優れているからです。あなたが言及したように、それを使用するにはエンティティのフィールドに注釈を付ける必要があります。既存のコードベースのサイズにもよるが、この作業は自明ではないかもしれない。

ほとんどの経験はHibernate Validatorであり、これは優れた高速JSR 303実装であることがわかりました。