ベンダーからの XML を検証し、それを XML タイプとして Oracle に保存する必要があります。
ここで、検証エンジンをトリガーするプロセスが必要です...これは検証エンジンを検証し、値を「YES」または「NO」としてインジケーターに保存します。たとえば、XML のアドレスが dB に存在しない場合、アドレス インジケーターを作成します。 「いいえ」として [別のプロセスで修正します...]
Spring 303 ですでに JSR303 を使用していますが、これは非常に効果的で使いやすいものです....しかし、フォーム バッキング オブジェクトと @valid を使用しています.....
ここで私のデザインに使用できますか...
または、このように言いましょう-
Spring の JSR-303 実装で、フォーム入力以外のオブジェクト フィールドを検証することは可能ですか?
非常に漠然とした質問であることは承知しています...さらに説明する必要がある場合はお知らせください
JSR-303 プロバイダー (ほとんどの場合、hibernate-validator) によって実行されるオブジェクトの検証のほとんどの作業。このプロセスにおける Spring の役割は最小限です。ユーザーのデータを解析し、それをオブジェクトにバインドして、このオブジェクトをバリデーターに渡すだけです。また、アプリケーションの起動時に、Spring がValidatorインスタンスを作成します。
したがって、このプロセスに干渉できます。検証されるオブジェクトを手動で作成し、Validatorインスタンスを取得してオブジェクトを彼に渡します。その結果、各フィールドのエラーを表す が得られSetますConstraintViolation。
このスキームの主な問題は、JSR-303 バリデーターがオブジェクトを操作する一方で、XML ドキュメントを操作することです。XML ドキュメントをオブジェクトにデシリアライズして検証し、エラーがなければ XML にシリアライズして DB に書き込みます。
Hibernate Validator マニュアルの次の部分を読むことをお勧めします: 2.2. 制約の検証Validatorインターフェイスといくつかの便利なメソッドvalidate()について説明validateProperty()しますvalidateValue()。
ここでの Spring の利点の 1 つは、他のすべての Spring Bean と同様にValidator、自分で作成する必要がないことですValidation.buildDefaultValidatorFactory().getValidator()。@Autowire
@Autowired
private Validator validator;