0

内部 Bean を含む複合 Bean があり、これらの内部 Bean の一部にも内部 Bean があります。この複合 Bean には、合計 200 以上のプロパティ (この Bean のプロパティ + 内部 Bean のプロパティ) があります。ユーザー入力の検証にJSR 303を使用しています。私の要件では、クロス フィールド Bean の検証を行うことをお勧めします。

同じことに関して、http://dwuysan.wordpress.com/2012/03/20/cross-field-validation-using-bean-validation-jsr-303/のようないくつかのブログや提案を調べました。同様の説明がここにあります: Cross field validation with Hibernate Validator (JSR 303)。

どちらも、クロス フィールド検証のクラス レベルの制約を定義するための同じアプローチを提案しています。彼らのアプローチはBeanUtils.getProperty()メソッドを使用することであり、Bean 検証の実行中に実行時にJava Reflectionsを使用します。

実行時に評価するリフレクションを使用して JSR 303 corss-field 制約を定義する (パフォーマンスの低下) か、Spring Validation やカスタム メソッドによるサービス レイヤーの検証などの他の検証戦略を使用するのが良いかどうか知りたいですか?

4

1 に答える 1

1

要件がいくつかのフィールド間検証ルールを実装することだけである場合は、ゲッターを呼び出すだけで関連するプロパティにアクセスする専用のクラス レベルの制約を実装することをお勧めします。これにより、制約がタイプセーブになり、リフレクションが回避されます。

フィールド間の検証が多く、それらすべてに対して専用の制約を作成するのが面倒な場合は、次のような一般的なアプローチで作業を@FieldMatch節約できます。ほとんどの場合、リフレクションのオーバーヘッドは無視できるはずです。パフォーマンスの低下が見られる場合でも、最も重要なケースに対して特定のクラス レベルの制約を実装できます。

于 2013-06-17T10:11:51.847 に答える