最近、動的データを送信する必要があります。つまり、対応する特定のフィールドタイプを明確にしてから、データ型の変換とフィールドの有効性の検証を実行する前に、データフィールド定義情報を分析および送信する必要があります。次に、ビジネス処理を行った後、データベースを送信し、一連の検証ロジックを自分で開発すると、サイクルが長すぎます。したがって、Spring検証の実装原則が分析され、さまざまな基礎となるバリデーターが再利用されました。ここでは、Spring検証原則を分析するプロセスは、詳細を説明することなく記録されます。
Spring検証の使用方法
Spring Beanを初期化するときに、BeanがJSR-303仕様に準拠しているかどうかを確認します
1.手動でBeanValidationPostProcessor Beanを追加します
2。@max、@min、@notemptyなどのモデルクラスの検証ルールを定義します
3。豆を宣言してください。包括的なコードは次のとおりです。
@beanpublic beanpostprocessor beanvalidationpostprocessor（）{return new beanvalidationpostprocessor（）;}@beanpublic usermodel getusermodel（）{usermodel usermodel = new usermodel（）; usermodel.setusername（null）; usermodel.setpassword（ "123"）; return usermodel;} @dataclass usermodel {@notnull（message = "username be null"）@pattern（regexp = "[a-za-z0-9 _] {5,10}」 @size（min = 5、max = 10、message = "パスワードの長さは違法です"）プライベート文字列パスワード;}4。BeanValidationPostProcessorInitializationの後にブール型のプロパティがありますが、これはデフォルトでは偽です。それが偽の場合、豆はポストプロセス前の前項化プロセスで検証されます。それ以外の場合、豆はポストプロセッアフテリメタル化プロセスで検証されています。
5.この検証では、SpringのBeanPostProcessorロジックを使用します
6. dovalidateメソッドが呼び出され、さらにvalidator.validateを呼び出すことを確認します。デフォルトのバリデーターはHibernateValidatorであり、検証-APIパッケージはJava仕様であり、デフォルトのスプリング仕様はHibernate-Validatorパッケージとして実装されています。この冬眠型非音波フレームワーク冬眠
保護されたvoid dovalidate（object bean）{assert.state（this.validator！= null、 "no validator set"）; set <constraintviolation <object >> result = this.validator.validate（bean）;7. hibernateValidatorは、デフォルトでvalidatorFactoryImplを呼び出してVALIBATORを生成し、validatorFactoryImplを展開します
メソッドレベルのJSR-303仕様をサポートします
1. MethodValidationPostProcessor Beanを手動で追加します
2. @validatedアノテーションをクラスに追加します（カスタムアノテーションもサポートされ、MethodValidationPostProcessor Beanを作成するときに渡されます）
3. @max、@min、@notempty、@notnullなど、メソッドのパラメーターに確認注釈を追加します。
@component@validatedpublic class beanformethodvalidation {public void validate（@notempty string name、@min（10）int age）{system.out.println（ "validate、name：" + name + "、age：" + age）; }}4。MethodValidationPostProcessorはAOPを使用してメソッドへの呼び出しを完了します
public void afterpropertiesset（）{pointcut pointcut = new `annotationMatchingPointCut`（this.validatedAnnotationType、true）; this.advisor = new `defaultPointCutadvisor`（PointCut、CreateMethodValidationAdvice（this.Validator））;}プロテクションのアドバイスCreatemEthodValidationAdvice（@Nullable Validator）{return（Validator！= null？null？new` MethodValidationInterceptor`（validator）：new MethodvalidationInterception）;5.基礎となるレイヤーは、デフォルトでvalidatorFactoryImplを呼び出してVALIBATORを生成し、検証因子は検証を完了します。
次のような直接エンコードコール検証ロジック
パブリッククラスの人{@notnull（message = "ジェンダーは空にすることはできません"）プライベートジェンダージェンダー; @min（10）private integer age; ...} validatorfactory validatorfactory = validation.builddefaultvalidatorfactory（）; validator validator = validatorfactory.getvalidator（）; person（）; setgender（gender.man.man.man.man.man.man.man.man.man.man.man.man.man.man.上記と同じように、validatorfactoryImplへのデフォルトの呼び出しが呼び出され、検証因子が生成され、バリデーターが特定の検証を完了します。
有効または検証済みの注釈を使用して、スプリングコントローラーメソッドパラメーターで確認するパラメーターを注釈付けします
1.まず、春のリクエストと呼び出しプロセスに精通してください
2。パラメーターの検証は、さまざまなリゾルバーの処理要求パラメーターのプロセス中に行われることがわかります。
3.基礎となるレイヤーは、DataBinderの検証方法を均一に呼び出します
4。データバインダーの役割：検証およびバインディング結果分析のサポートを含む、ターゲットオブジェクトにプロパティ値を設定できるバインダー、つまりバインダーはリクエストによって送信された文字列形式のパラメーターを処理し、サーバーが本当に必要とするタイプに変換します。バインダーは検証のサポートを提供し、検証結果を保存できます。
5. DataBinderのVALIDATORは、デフォルトで構成可能なWebbindinitInitializerで初期化されます。 OptionalValidatorFactoryBeanはデフォルトで使用されます。この豆は、LocalValidatorFactoryBeanを継承します。 LocalValidatorFactoryBeanは、BalidatorFactory、カスタム検証プロパティなどなどのさまざまな検証情報を組み合わせて、ValidatorFactoryImplを使用してデフォルトでValidatorを取得します。
この時点で、すべての手がかりはvalidatorFactoryImplを指しています。次の分析は次のとおりです
public Validator `getValidator`() { return `createValidator`(constraintValidatorManager.getDefaultConstraintValidatorFactory(), valueExtractorManager, validatorFactoryScopedContext, methodValidationConfiguration );}Validator `createValidator`(ConstraintValidatorFactory constraintValidatorFactory, ValueExtractorManager ValueExtractorManager、ValidatorFactoryScopedContext ValidatorFactoryScopedContext、MethodValidationConfiguration MethodValidationConfiguration）{beanmetadatamanager beanmetadatamanager = beanmetadatamanagers.computeifabsent（New BeanmetadatAmanagerkey（ validatorFactoryScopedContext.getParameternAmeprovider（）、ValueExtractorManager、MethodValidationConfiguration）、Key-> new BeanMetadatAmanager（ `Constrainthelper`、executableHelper、typereSolutionhelper、viladatorefactoryscopedcontext.getparameternameprovider（ validationOrderGenerator、BuildDataProviders（）、MethodValidationConfiguration））; `new ValidatorImpl`（ConstraintValidatorFactory、BeanMetadatamanager、ValueExtractorManager、ConstraintValidatormanager、ValidationOrderGenerator、ValidatorFinalScopedContext）;} Public Final <> Set <ConstraintViolation <t >> set <constraintviolation <t >> belidate、<？ messages.validatedObjectMustnotbenull（））; SanityCheckGroups（グループ）; validationContext <t> validationContext = `getValidationContextBuilder（）。forvalidate（object）`; if（！validationContext.getRootbeanMetadata（）。hasconstraints（））{return collections.emptyset（）; } validationorder validationOrder = sequineGroupValidationOrder（グループ）; ValueContext <？、object> ValueContext = `ValueContext.getLocalExecutionContext`（validatorScopedContext.getParameternAmeprovider（）、object、validationContext.getRootbeanMetadata（）、patimpl.createrootpath（）; return validateincontext（validationContext、valueContext、validationorder）;}1。getValidator-> createvalidator-> balidatorimpl-> validate
実行プロセス中に、BeanMetadatAmanager、ValidationContext、ValueContext、およびその他のコンテンツがカプセル化されています。これは、確認中に検証中に使用されるコンテキスト情報です。など、コンテンツは比較的複雑です。
2。グループ検証は無視され、デフォルトのグループ処理はvalidateconstraintsfordefaultgroup-> valivateconstraintsforsedefaultgroupElement-> validAtemetaconstraintです（注：Beanタイプとその親クラスとインターフェースのすべての検証を維持します。
3.メタコンストラリントのdovalidateconstraintメソッドを引き続き呼び出し、さまざまな注釈タイプに従って異なる制約ツリーに従います。
public static <u extends annotation> constrainttree <u> of（constraintdescriptorimpl <u> composingDescriptor、type validatedValueetype）{if（composingsDescriptor.getCompositingConstriminimpls（）。 } else {return new composingConstrainttree <>（composingDescriptor、validatedValueetype）; }}4.私は何を簡単に行けばいいですか、そして何を作曲するべきですか？どちらも「getInitializedConstraintalidator」制約の方法を呼び出すためです。この手順は、注釈（Decimalmax、Notemptyなど）に対応するバリデーターを取得し、バリッタを初期化するために使用されます。
5. ConstraintHelperクラスは、すべてのビルトインバリデーターを維持し、検証注釈（DecimalMaxなど）に従ってそれらを分類します。 Validatorの説明クラスは、次のように、Validatorの一般的なテンプレート（BigDecimalなど）を維持しています。
PutConstraints（tmpconstraints、decimalmax.class、arrays.aslist（decimalmaxvalidator forbigdecimal.class、decimalmaxvalidatorfordouble.class、decimalmaxvalidator.forforforforforforforforforforforforforforforforforforforforforforforforforforforforforforforforforforforforforforforforforforforforforforforforforforforforfordator）decimalmaxvalidatorfordouble.class、 decimalmaxvalidatorfornumber.class、decimalmaxvalidatorforcharecence.class、decimalmaxvalidatorformonetaryamount.class））;
特定のBeanクラスのバリデーターを取得するとき、最初にアノテーションに従ってすべてのバリデーターを取得します。対応するメソッドはConstraintManager.findMatchingValidAtordEScriptorであり、チェックされるオブジェクトのタイプに従って一意のバリデーターを取得します。
6.次に、コンテキスト情報に基づいて初期化されたvalidatorを使用してから、ValidatorのisValidメソッドを呼び出して確認します
上記はこの記事のすべての内容です。みんなの学習に役立つことを願っています。誰もがwulin.comをもっとサポートすることを願っています。