深さからデータ検証@Valid役割（カスケードチェック）を習得します

各1

2人のNBAのジョークがあります。一つは才能のブライアント、ジェームズ、そして第二に、ない技術ではありません

序文

Bean Validation：この章の基本原則の終了後、次のステップは、小さな呉服パートナーが最も懸念しているある記事の使用。
あなたが使用したい場合はBean Validation、データの検証を、私は強く、小さなパートナーが使用することができますことを信じて、大きな前提があると推定されている：Spring MVC環境を。私はほとんど、一瞬のために非常に簡単な調査だった99%人の中で唯一のデータ検証を使用しているレベル、およびほとんどすべての人々の、それがなければなりませんチェックするために使用するために協力〜パラメータをSpring MVCController90%@RequestBodyJavaBean

そう理解した場合はBean Validation使用を、それはすべての後に、春が包まあるあなたはそれが実際に行うのは難しい本当に知っている、少しも一方的です。
私の記事に泊まっは、各記事私はあなたにいくつかの異なった風景の味をもたらすでしょう、この章では、例外ではありません、スタイルを知っているし、あなたがデータチェックを知っているだろうSpring〜の枠組みの外で何か

パケットのチェックサム

本当に使用することは非常に簡単ですので、私の前の原則記事では、パケットのチェックサムは、実際に言うことはあまり必要ではありません。ここでは、ユースケースそれを確認するためのパケットは次のようになります。

@Getter
@Setter
@ToString
public class Person {
    // 错误消息message是可以自定义的
    @NotNull(message = "{message} -> 名字不能为null", groups = Simple.class)
    public String name;
    @Max(value = 10, groups = Simple.class)
    @Positive(groups = Default.class) // 内置的分组：default
    public Integer age;

    @NotNull(groups = Complex.class)
    @NotEmpty(groups = Complex.class)
    private List<@Email String> emails;
    @Future(groups = Complex.class)
    private Date start;

    // 定义两个组 Simple组和Complex组
    interface Simple {
    }
    interface Complex {

    }
}

パケットチェックを実行します。

    public static void main(String[] args) {
        Person person = new Person();
        //person.setName("fsx");
        person.setAge(18);
        // email校验：虽然是List都可以校验哦
        person.setEmails(Arrays.asList("[email protected]", "[email protected]", "aaa.com"));
        //person.setStart(new Date()); //start 需要是一个将来的时间: Sun Jul 21 10:45:03 CST 2019
        //person.setStart(new Date(System.currentTimeMillis() + 10000)); //校验通过

        HibernateValidatorConfiguration configure = Validation.byProvider(HibernateValidator.class).configure();
        ValidatorFactory validatorFactory = configure.failFast(false).buildValidatorFactory();
        // 根据validatorFactory拿到一个Validator
        Validator validator = validatorFactory.getValidator();


        // 分组校验（可以区分对待Default组、Simple组、Complex组）
        Set<ConstraintViolation<Person>> result = validator.validate(person, Person.Simple.class);
        //Set<ConstraintViolation<Person>> result = validator.validate(person, Person.Complex.class);

        // 对结果进行遍历输出
        result.stream().map(v -> v.getPropertyPath() + " " + v.getMessage() + ": " + v.getInvalidValue())
                .forEach(System.out::println);

    }

印刷を実行します。

age 最大不能超过10: 18
name {message} -> 名字不能为null -> 名字不能为null: null

あなたは視覚的にチェックがのみ行われる効果、見ることができますPerson.Simple.class。このGroupグループに制約を-

Spring MVCのに拘束利用シナリオをグループ化すると、まだ比較的多くのですが、ことに留意すべきである：javax.validation.Valid指定されていないパケットを提供していますが、org.springframework.validation.annotation.Validated拡張子は直接注釈レベルでグループ化を指定する機能を提供します

@Validコメント

私たちは知っていることをJSR提供し@Valid、この論文に先立っての使用のためのコメントを、大半がで小さなパートナーですController組み合わせて、@RequestBodyそれを使用するために一緒に動作しますが、この記事の後、あなたはそれを新しい理解を与えているだろう〜

検証のための注釈== 特性カスケード、メソッドパラメータ、またはメソッドの戻り型。==
場合認証属性メソッドパラメータまたはメソッドの戻り型、さらにオブジェクトおよびその属性検証制約、上に定義されました。此行为是递归应用的。

:::理解するために@Valid、あなたはそれに対処する時間です知っている必要があります:::

MetaDataProvider

メタデータプロバイダ：制約に関連するメタデータ（例えば、制約、配列のデフォルトセット、等）Provider。次のようにその役割と特徴は以下のとおりです。

別のメタデータに基づいて：XML、アノテーションとして。（マッピングプログラムがあります）これらの3つのタイプが。に対応する列挙クラス：

public enum ConfigurationSource {
    ANNOTATION( 0 ),
    XML( 1 ),
    API( 2 ); //programmatic API
}

MetaDataProvider唯一のリターンクラス導くように構成されたメタデータを
これは、（インタフェースからメタデータをマージ、スーパークラスを処理しません简单的说你@Valid放在接口处是无效的）

public interface MetaDataProvider {

    // 将**注解处理选项**归还给此Provider配置。  它的唯一实现类为：AnnotationProcessingOptionsImpl
    // 它可以配置比如：areMemberConstraintsIgnoredFor  areReturnValueConstraintsIgnoredFor
    // 也就说可以配置：让免于被校验~~~~~~(开绿灯用的)
    AnnotationProcessingOptions getAnnotationProcessingOptions();
    // 返回作用在此Bean上面的`BeanConfiguration`   若没有就返回null了
    // BeanConfiguration持有ConfigurationSource的引用~
    <T> BeanConfiguration<? super T> getBeanConfiguration(Class<T> beanClass);
    
}

// 表示源于一个ConfigurationSource的一个Java类型的完整约束相关配置。  包含字段、方法、类级别上的元数据
// 当然还包含有默认组序列上的元数据（使用较少）
public class BeanConfiguration<T> {
    // 三种来源的枚举
    private final ConfigurationSource source;
    private final Class<T> beanClass;
    // ConstrainedElement表示待校验的元素，可以知道它会如下四个子类：
    // ConstrainedField/ConstrainedType/ConstrainedParameter/ConstrainedExecutable
    
    // 注意：ConstrainedExecutable持有的是java.lang.reflect.Executable对象
    //它的两个子类是java.lang.reflect.Method和Constructor
    private final Set<ConstrainedElement> constrainedElements;

    private final List<Class<?>> defaultGroupSequence;
    private final DefaultGroupSequenceProvider<? super T> defaultGroupSequenceProvider;
    ... // 它自己并不处理什么逻辑，参数都是通过构造器传进来的
}

その継承ツリー：
ここに画像を挿入説明
上記メタデータの種類の三種類に対応する3つの実装クラス。本論文では、ジャストフォーカスと関連のメモする必要があることは明らかです。AnnotationMetaDataProvider

AnnotationMetaDataProvider

このメタデータ注釈はマークからのもの、それはあり、Hibernate Validationデフォルトでconfiguration source。ここでは、付いたハンドルます@Valid要素〜

public class AnnotationMetaDataProvider implements MetaDataProvider {

    private final ConstraintHelper constraintHelper;
    private final TypeResolutionHelper typeResolutionHelper;
    private final AnnotationProcessingOptions annotationProcessingOptions;
    private final ValueExtractorManager valueExtractorManager;

    // 这是一个非常重要的属性，它会记录着当前Bean  所有的待校验的Bean信息~~~
    private final BeanConfiguration<Object> objectBeanConfiguration;

    // 唯一构造函数
    public AnnotationMetaDataProvider(ConstraintHelper constraintHelper,
            TypeResolutionHelper typeResolutionHelper,
            ValueExtractorManager valueExtractorManager,
            AnnotationProcessingOptions annotationProcessingOptions) {
        this.constraintHelper = constraintHelper;
        this.typeResolutionHelper = typeResolutionHelper;
        this.valueExtractorManager = valueExtractorManager;
        this.annotationProcessingOptions = annotationProcessingOptions;

        // 默认情况下，它去把Object相关的所有的方法都retrieve:检索出来放着  我比较费解这件事~~~  
        // 后面才发现：一切为了效率
        this.objectBeanConfiguration = retrieveBeanConfiguration( Object.class );
    }

    // 实现接口方法
    @Override
    public AnnotationProcessingOptions getAnnotationProcessingOptions() {
        return new AnnotationProcessingOptionsImpl();
    }


    // 如果你的Bean是Object  就直接返回了~~~（大多数情况下  都是Object）
    @Override
    @SuppressWarnings("unchecked")
    public <T> BeanConfiguration<T> getBeanConfiguration(Class<T> beanClass) {
        if ( Object.class.equals( beanClass ) ) {
            return (BeanConfiguration<T>) objectBeanConfiguration;
        }
        return retrieveBeanConfiguration( beanClass );
    }
}

図から分かるように、コアロジックが解析しretrieveBeanConfiguration()、このプライベートメソッドを。このメソッドを呼び出し元の2つのエントリ（コンストラクタ、界面法）まとめ：

ValidatorFactory.getValidator()初期化するときに、自分でするときのバリデータを取得しnew、以下のようにコールスタックを：
呼び出しValidator.validate()メソッドがときbeanMetaDataManager.getBeanMetaData( rootBeanClass )、それはすべての初期化を経由するmetaDataProviders（デフォルトでは2、XMLの方法がない）、すべてのアウトを取るBeanConfigurationためにBeanMetaDataBuilder、最終的にこのBeanの部分を構築しますBeanMetaData。記載されているこの事の考慮事項は次のとおりです
。1.治療がMetaDataProviderときに呼び出されるClassHierarchyHelper.getHierarchy( beanClass )メソッドだけでなく、このクラスを扱います。このクラス自身とすべての親クラスを取得した後、への統一provider.getBeanConfiguration( clazz )を扱う（つまり、クラスのいずれかが再びObjectクラスに対処しますと言うことです）

`retrieveBeanConfiguration()`ディテール

はっきり内側から、であるこの方法は、Beanプロパティ、メソッド、または検証されるように構成などを取得しますConstrainedElement项。

    private <T> BeanConfiguration<T> retrieveBeanConfiguration(Class<T> beanClass) {
        // 它检索的范围是：clazz.getDeclaredFields()  什么意思：就是搜集到本类所有的字段  包括private等等  但是不包括父类的所有字段
        Set<ConstrainedElement> constrainedElements = getFieldMetaData( beanClass );
        constrainedElements.addAll( getMethodMetaData( beanClass ) );
        constrainedElements.addAll( getConstructorMetaData( beanClass ) );

        //TODO GM: currently class level constraints are represented by a PropertyMetaData. This
        //works but seems somewhat unnatural
        // 这个TODO很有意思：当前，类级约束由PropertyMetadata表示。这是可行的，但似乎有点不自然
        // ReturnValueMetaData、ExecutableMetaData、ParameterMetaData、PropertyMetaData

        // 总之吧：此处就是把类级别的校验器放进来了（这个set大部分时候都是空的）
        Set<MetaConstraint<?>> classLevelConstraints = getClassLevelConstraints( beanClass );
        if (!classLevelConstraints.isEmpty()) {
            ConstrainedType classLevelMetaData = new ConstrainedType(ConfigurationSource.ANNOTATION, beanClass, classLevelConstraints);
            constrainedElements.add(classLevelMetaData);
        }
        
        // 组装成一个BeanConfiguration返回
        return new BeanConfiguration<>(ConfigurationSource.ANNOTATION, beanClass,
                constrainedElements, 
                getDefaultGroupSequence( beanClass ),  //此类上标注的所有@GroupSequence注解
                getDefaultGroupSequenceProvider( beanClass ) // 此类上标注的所有@GroupSequenceProvider注解
        );
    }

このステップでは、豆置くフィールド、メソッドなどの項目が抽出され検証されます。パリティデモの例取るPersonクラスを、最終的な結果はBeanConfiguration以下の2 :(）
ここに画像を挿入説明

この直感的な結論は単純なクラスファクト見ることができるエントリが含まれているの多くを。

此处说一句：项是有这么多，但是并不是每一个都需要走验证逻辑的。因为毕竟大多数项上面并没有约束（注解），大多数ConstrainedElement.getConstraints()为空嘛~

总得来说，我个人建议不能光只记忆结论，因为那很容易忘记，所以还是得稍微深入一点，让记忆更深刻吧。那就从下面四个方面深入：

检索Field：getFieldMetaData( beanClass )

拿到本类所有字段Field：clazz.getDeclaredFields()
把每个Field都包装成ConstrainedElement存放起来~~~
1. 注意：此步骤完成了对每个Field上标注的注解进行了保存

检索Method：getMethodMetaData( beanClass )

拿到本类所有的方法Method：clazz.getDeclaredMethods()
排除掉静态方法和合成(isSynthetic)方法
把每个Method都转换成一个ConstrainedExecutable装着~~(ConstrainedExecutable也是个ConstrainedElement)。在此期间它完成了如下事（方法和构造器都复杂点，因为包含入参和返回值）：
1. 找到方法上所有的注解保存起来
2. 处理入参、返回值（包括自动判断是作用在入参还是返回值上）

检索Constructor：getConstructorMetaData( beanClass )

完全同处理Method，略

检索Type：getClassLevelConstraints( beanClass )
找打标注在此类上的所有的注解，转换成ConstraintDescriptor
对已经找到每个ConstraintDescriptor进行处理，最终都转换Set<MetaConstraint<?>>这个类型
1.
把Set<MetaConstraint<?>>用一个ConstrainedType包装起来（ConstrainedType是个ConstrainedElement）

==关于级联校验此处补充说明一点，处理Type，都会处理级联校验情况，并且还是递归处理：==
也就是这个方法（课件@Valid在此处生效）：

    // type解释：分如下N中情况
    // Field为：.getGenericType() // 字段的类型
    // Method为：.getGenericReturnType() // 返回值类型
    // Constructor：.getDeclaringClass() // 构造器所在类

    // annotatedElement：可不一定说一定要有注解才能进来（每个字段、方法、构造器等都能传进来）
    private CascadingMetaDataBuilder getCascadingMetaData(Type type, AnnotatedElement annotatedElement, Map<TypeVariable<?>, CascadingMetaDataBuilder> containerElementTypesCascadingMetaData) {
        return CascadingMetaDataBuilder.annotatedObject( type, annotatedElement.isAnnotationPresent( Valid.class ), containerElementTypesCascadingMetaData, getGroupConversions( annotatedElement ) );
    }

这里对我们理解级联校验最重要的一句是：annotatedElement.isAnnotationPresent(Valid.class)。也就是说：若元素被此注解标注了，那就证明需要对它进行级联校验，这就是JSR定位@Valid的作用~

Spring提升了它？？？请关注后文Spring对它的应用吧~

`ConstraintValidator.isValid()`调用处

我们知道，每个约束注解都是交给约束校验器ConstraintValidator.isValid()这个方法来处理的，它被调用(生效)的地方在此(唯一处)：

public abstract class ConstraintTree<A extends Annotation> {
    ...
    protected final <T, V> Set<ConstraintViolation<T>> validateSingleConstraint(ValidationContext<T> executionContext,
            ValueContext<?, ?> valueContext,
            ConstraintValidatorContextImpl constraintValidatorContext,
            ConstraintValidator<A, V> validator) {
        ...
        V validatedValue = (V) valueContext.getCurrentValidatedValue();
        isValid = validator.isValid( validatedValue, constraintValidatorContext );
        ...
        // 显然校验不通过就返回错误消息  否则返回空集合
        if ( !isValid ) {
            return executionContext.createConstraintViolations(valueContext, constraintValidatorContext);
        }
        return Collections.emptySet();
    }
    ...
}

这个方法的调用，会在执行每个Group的时候

success = metaConstraint.validateConstraint( validationContext, valueContext );

MetaConstraint在上面检索的时候就已经准备好了，最后通过ConstrainedElement.getConstraints就拿到了每个元素的校验器们，继续调用

// ConstraintTree<A>
boolean validationResult = constraintTree.validateConstraints( executionContext, valueContext );

so，最终就调用到了isValid这个真正做事的方法上了。

==说了这么多，你可能还云里雾里，那么就show一把吧：==

Demo Show

上面用一个示例校验Person这个JavaBean了，但是你会发现示例中我们全都是校验的Field属性。从理论里我们知道了Bean Validation它是有校验方法、构造器、入参甚至递归校验级联属性的能力的：

校验属性Field

略

校验Method入参、返回值

校验Constructor入参、返回值

既校验入参，同时也校验返回值

これらを直接、使用することはできませんが、実行時に検証する必要があります。参照の特定の使用：[春]（デフォルトはSpring MVCの@ValidだけのJavaBeanに確認することができます使用）小さなホームコントローラは、タイルのデータ検証パラメータの実装をサポートします

カスケードチェック

何が、実際には、オブジェクトのメンバーの存在は、パリティ付きカスケードチェックカスケードされ、その検証を完了しなければなりません。実際には、このシナリオでは、このような参照として、より一般的であるPerson、オブジェクト、また、保持しているChildオブジェクトを、私たちは完了していないだけ持ってPersonチェックし、上にもまだある子供でプロパティのチェック：

@Getter
@Setter
@ToString
public class Person {

    @NotNull
    private String name;
    @NotNull
    @Positive
    private Integer age;
    @Valid
    @NotNull
    private InnerChild child;

    @Getter
    @Setter
    @ToString
    public static class InnerChild {
        @NotNull
        private String name;
        @NotNull
        @Positive
        private Integer age;
    }

}

次のようにチェックするロジックは次のとおりです。

    public static void main(String[] args) {
        Person person = new Person();
        person.setName("fsx");
        Person.InnerChild child = new Person.InnerChild();
        child.setName("fsx-son");
        child.setAge(-1);
        person.setChild(child); // 放进去

        Validator validator = Validation.byProvider(HibernateValidator.class).configure().failFast(false)
                .buildValidatorFactory().getValidator();
        Set<ConstraintViolation<Person>> result = validator.validate(person);

        // 输出错误消息
        result.stream().map(v -> v.getPropertyPath() + " " + v.getMessage() + ": " + v.getInvalidValue())
                .forEach(System.out::println);
    }

実行します。

child.age 必须是正数: -1
age 不能为null: null

child.ageこのカスケード属性検証に成功している〜

概要

この記事では、データ検証（バリデーション豆）、データ検証のための基本的な使用は、特に中、困難されていない理解する価値があると言うSpringより簡単な使用環境を-

知識交換

若文章格式混乱，可点击：説明リンク-テキストリンク-テキストリンク-テキストリンク-テキストリンク

==最後に：あなたはあなたにこの記事が参考に思われる場合は、賞賛の聖歌を指すように望むことができます。もちろん、友人のサークルは、より小さなパートナーも見ているので、共有する作者本人许可的~==を

技術内容に興味を持っている場合、グループWX交換に参加することができますJava高工、架构师3群。
グループは、2次元コードを失敗した場合、WX番号を追加してください：fsx641385712（または2次元コードがWXの下でスキャンされます）。そして注："java入群"単語は、手動でグループに招待されます