1

JSR-303 (Bean Validation) では、作成する制約バリデーターごとに特別なアノテーションを定義する必要があります。@Maxこれは、再利用可能な制約バリデータ (標準の@NotNull、 など)を作成している場合に完全に理にかなっています。

ただし、実際には、検証済みのすべての Bean には、より複雑なビジネス検証を行うための独自のバリデーターが必要です。通常の JSR-303 実装では、バリデーターごとに個別のアノテーションを作成する必要があります。これにより、開発者は 1 回限りのアノテーションを作成することを余儀なくされ、Bean 検証の全体的な概念がばかげているように見えます。JSR-303 がある種の委任制約アノテーションを提供する場合、1 回限りのアノテーションの必要性を回避できます@ValidateBy(validator=my.custom.Validator)。

今私の質問に：

  • JSR-303 にそのようなユースケースが含まれていないのはなぜですか?
  • これに関連する公式の議論はありますか (私は何も見つけることができませんでした)?
  • そのような機能を提供する JSR-303 ライブラリはありますか (それを実装するのが難しいというわけではありません)?

更新 1 - 特定のユースケース (この質問につながった)

非常に豊富なビジネス モデル (40 の管理可能なエンティティ、20 の埋め込み可能なエンティティ、25 の読み取り専用エンティティ) を備えた中程度のエンタープライズ アプリケーションがあります。これは、多数の HTML フォームがあることを意味します。各フォームは、JSR-303 アノテーション付きの指定されたフォーム Bean (70 フォーム Bean) によって支えられています。一部のフォームでは、自明ではない独自の検証が必要です (たとえば、配信タイプが電子メールの場合、連絡先電子メールを設定する必要があります...)。JSR-303 では、33 個の (不要な 1 回限りの) アノテーションを持つ 33 個のフォーム Bean 固有のバリデーターがあります。

Java クラス (エンティティ、コントローラー、DAO、DTO、マッパー、バリデーターなど... 現在、これで 800 個の.javaファイルが作成されます) の数があるため、ボイラープレート コードを使用するのは好きではありません。

4

2 に答える 2

2

Bean Validation のコア原則の 1 つは型安全性です。などの特定の制約注釈を使用すると@Max、@Size許容される最大値などのカスタム属性をタイプセーフな方法で指定およびアクセスできます。

選択されたアプローチにより、検証エンジンは、ユーザーがバリデータ クラスを指定する必要がなく、注釈付き要素の型に基づいて適切なバリデータ実装を選択することもできます。したがって、ある意味で、これは複雑さを制約のユーザーから制約の作成者に少しシフトします。

あなたが言うように、これをカスタム制約として実装することは難しくありません。ただし、これにより、たとえばHibernate Validator によって提供される注釈プロセッサを介して、コンパイル時の制約の正確性のチェックが無効になることに注意してください。これは、文字列プロパティに誤って指定され@Pastた制約を検出できましたが、 を介して指定された一致しないバリデータ型を検出できませんでした@ValidatedBy。

要件が完全な Bean のカスタム検証ロジック (クラスレベルの検証) に関するものである場合は、その Bean のメソッドで次のように実装することを検討できます。

@AssertTrue
public boolean isValid() {
    //custom validation logic
}

または、Hibernate Validator によって提供される@ScriptAssert制約を活用することもできます。

于 2013-11-06T12:17:29.093 に答える