最近要做動(dòng)態(tài)數(shù)據(jù)的提交處理，即需要分析提交數(shù)據(jù)字段定義信息后才能明確對(duì)應(yīng)的具體字段類型，進(jìn)而做數(shù)據(jù)類型轉(zhuǎn)換和字段有效性校驗(yàn)，然后做業(yè)務(wù)處理后提交數(shù)據(jù)庫(kù)，自己開發(fā)一套校驗(yàn)邏輯的話周期太長(zhǎng)，因此分析了spring validation的實(shí)現(xiàn)原理，復(fù)用了其底層花樣繁多的validator，在此將分析spring validation原理的過程記錄下，不深入細(xì)節(jié)
如何使用spring validation
spring bean初始化時(shí)校驗(yàn)bean是否符合jsr-303規(guī)范
1、手動(dòng)添加beanvalidationpostprocessor bean
2、在model類中定義校驗(yàn)規(guī)則，如@max、@min、@notempty
3、聲明bean，綜合代碼如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
@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 can not be null") @pattern(regexp = "[a-za-z0-9_]{5,10}", message = "username is illegal") private string username; @size(min = 5, max = 10, message = "password's length is illegal") private string password;} |
4、beanvalidationpostprocessor bean內(nèi)部有個(gè)boolean類型的屬性afterinitialization，默認(rèn)是false，如果是false，在postprocessbeforeinitialization過程中對(duì)bean進(jìn)行驗(yàn)證，否則在postprocessafterinitialization過程對(duì)bean進(jìn)行驗(yàn)證
5、此種校驗(yàn)使用了spring的beanpostprocessor邏輯
6、校驗(yàn)底層調(diào)用了dovalidate方法，進(jìn)一步調(diào)用validator.validate，默認(rèn)validator為hibernatevalidator，validation-api包為java規(guī)范，spring默認(rèn)的規(guī)范實(shí)現(xiàn)為hibernate-validator包，此hibernate非orm框架hibernate
|
1
2
3
|
protected void dovalidate(object bean) { assert.state(this.validator != null, "no validator set"); set<constraintviolation<object>> result = this.validator.validate(bean); |
7、hibernatevalidator默認(rèn)調(diào)用validatorfactoryimpl來生成validator，后面展開將validatorfactoryimpl
支持方法級(jí)別的jsr-303規(guī)范
1、手動(dòng)添加methodvalidationpostprocessor bean
2、類上加上@validated注解（也支持自定義注解，創(chuàng)建methodvalidationpostprocessor bean時(shí)傳入）
3、在方法的參數(shù)中加上驗(yàn)證注解，比如@max、@min、@notempty、@notnull等，如
|
1
2
3
4
5
6
7
|
@component@validatedpublic class beanformethodvalidation { public void validate(@notempty string name, @min(10) int age) { system.out.println("validate, name: " + name + ", age: " + age); }} |
4、methodvalidationpostprocessor內(nèi)部使用aop完成對(duì)方法的調(diào)用
|
1
2
3
4
5
6
7
|
public void afterpropertiesset() { pointcut pointcut = new `annotationmatchingpointcut`(this.validatedannotationtype, true); this.advisor = new `defaultpointcutadvisor`(pointcut, createmethodvalidationadvice(this.validator));}protected advice createmethodvalidationadvice(@nullable validator validator) { return (validator != null ? new `methodvalidationinterceptor`(validator) : new methodvalidationinterceptor());} |
5、底層同樣默認(rèn)調(diào)用validatorfactoryimpl來生成validator，由validator完成校驗(yàn)
直接編碼調(diào)用校驗(yàn)邏輯，如
|
1
2
3
4
5
6
7
8
9
10
11
12
|
public class person {@notnull(message = "性別不能為空")private gender gender;@min(10)private integer age;...}validatorfactory validatorfactory = validation.builddefaultvalidatorfactory();validator validator = validatorfactory.getvalidator();person person = new person();person.setgender(gender.man);validator.validate(person); |
同上，默認(rèn)調(diào)用validatorfactoryimpl來生成validator，由validator完成具體校驗(yàn)
在spring controller方法參數(shù)中使用valid或validated注解標(biāo)注待校驗(yàn)參數(shù)
1、先熟悉下spring的請(qǐng)求調(diào)用流程
2、可以看到在各種resolver處理請(qǐng)求參數(shù)的過程中做了參數(shù)校驗(yàn)
3、底層統(tǒng)一調(diào)用了databinder的validate方法
4、databinder的作用：binder that allows for setting property values onto a target object, including support for validation and binding result analysis，也就是binder處理了request提交的字符串形式的參數(shù)，將其轉(zhuǎn)換成服務(wù)端真正需要的類型，binder提供了對(duì)validation的支持，可以存放校驗(yàn)結(jié)果
5、databinder的validator默認(rèn)在configurablewebbindinginitializer中初始化，默認(rèn)使用optionalvalidatorfactorybean，該bean繼承了localvalidatorfactorybean，localvalidatorfactorybean組合了validatorfactory、自定義校驗(yàn)屬性等各種校驗(yàn)會(huì)用到的信息，默認(rèn)使用validatorfactoryimpl來獲取validator
至此，所有的線索都指向了validatorfactoryimpl，下面分析下該類
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
|
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, validatorfactoryscopedcontext.getparameternameprovider(), valueextractormanager, validationordergenerator, builddataproviders(), methodvalidationconfiguration ) ); return `new validatorimpl`( constraintvalidatorfactory, beanmetadatamanager, valueextractormanager, constraintvalidatormanager, validationordergenerator, validatorfactoryscopedcontext );}public final <t> set<constraintviolation<t>> validate(t object, class<?>... groups) { contracts.assertnotnull( object, messages.validatedobjectmustnotbenull() ); sanitycheckgroups( groups ); validationcontext<t> validationcontext = `getvalidationcontextbuilder().forvalidate( object )`; if ( !validationcontext.getrootbeanmetadata().hasconstraints() ) { return collections.emptyset(); } validationorder validationorder = determinegroupvalidationorder( groups ); valuecontext<?, object> valuecontext = `valuecontext.getlocalexecutioncontext`( validatorscopedcontext.getparameternameprovider(), object, validationcontext.getrootbeanmetadata(), pathimpl.createrootpath() ); return validateincontext( validationcontext, valuecontext, validationorder );} |
1、getvalidator->createvalidator->validatorimpl->validate
在執(zhí)行過程中封裝了beanmetadatamanager、validationcontext、valuecontext等內(nèi)容，都是校驗(yàn)時(shí)會(huì)用到的上下文信息，如待校驗(yàn)bean的所有校驗(yàn)項(xiàng)（含父類和接口）、property、method parameter的校驗(yàn)信息，從validatorfactoryscopedcontext繼承過來的validator通用的各種工具類（如message、script等的處理）等，內(nèi)容比較復(fù)雜
2、分組（group）校驗(yàn)忽略，來到默認(rèn)分組處理validateconstraintsfordefaultgroup->validateconstraintsforsingledefaultgroupelement->validatemetaconstraint(注：metaconstraints維護(hù)了該bean類型及其父類、接口的所有校驗(yàn)，需要遍歷調(diào)用validatemetaconstraint)
3、繼續(xù)調(diào)用metaconstraint的dovalidateconstraint方法，根據(jù)不同的annotation type走不同的constrainttree
|
1
2
3
4
5
6
7
8
|
public static <u extends annotation> constrainttree<u> of(constraintdescriptorimpl<u> composingdescriptor, type validatedvaluetype) { if ( composingdescriptor.getcomposingconstraintimpls().isempty() ) { return new simpleconstrainttree<>( composingdescriptor, validatedvaluetype ); } else { return new composingconstrainttree<>( composingdescriptor, validatedvaluetype ); }} |
4、具體哪些走simple，哪些走composing暫且不管，因?yàn)槎叨颊{(diào)用了constrainttree的'getinitializedconstraintvalidator'方法，該步用來獲取校驗(yàn)annotation（如decimalmax、notempty等）對(duì)應(yīng)的validator并初始化validator
5、 constrainthelper 類維護(hù)了所有builtin的validator，并根據(jù)校驗(yàn)annotation（如decimalmax）分類，validator的描述類中維護(hù)了該validator的泛型模板（如bigdecimal），如下：
|
1
2
3
4
5
6
7
8
9
10
|
putconstraints( tmpconstraints, decimalmax.class, arrays.aslist( decimalmaxvalidatorforbigdecimal.class, decimalmaxvalidatorforbiginteger.class, decimalmaxvalidatorfordouble.class, decimalmaxvalidatorforfloat.class, decimalmaxvalidatorforlong.class, decimalmaxvalidatorfornumber.class, decimalmaxvalidatorforcharsequence.class, decimalmaxvalidatorformonetaryamount.class) ); |
在獲取具體bean類的validator時(shí)，先根據(jù)annotation獲取所有的validator，對(duì)應(yīng)方法是constraintmanager.findmatchingvalidatordescriptor，然后根據(jù)被校驗(yàn)對(duì)象的類型獲取唯一的validator
6、然后根據(jù)上下文信息initializevalidator，進(jìn)而調(diào)用validator的isvalid方法校驗(yàn)
以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持服務(wù)器之家。
原文鏈接：https://juejin.im/post/5b408c18f265da0f894b4d47
