Spring集成JSR-303 BeanValidation详解与约束实现

5星 · 超过95%的资源需积分: 16 115 浏览量更新于2024-07-23 收藏 408KB PDF 举报

Spring框架中的JSR-303 BeanValidation是基于Java Bean约束规范（JSR 303）的一个实现，它提供了对Java对象进行验证的能力，使得开发者可以轻松地在业务逻辑层面上确保数据的正确性和一致性。这个帮助文档详细介绍了如何在Spring环境中利用JSR-303进行验证，包括专家组、规范目标、约束定义、验证过程以及相关的API和最佳实践。 1. **专家组与规范目标**: - JSR-303由Emmanuel Bernard代表Red Hat公司领导，目标是为Java Bean提供一种标准化的验证机制，允许开发人员在应用程序的各个层面（如对象、字段和属性）添加验证规则。 2. **约束定义**: - 使用约束注解（如`@NotNull`, `@Size`, `@Email`等）来定义约束，这些注解有特定的属性，如`message`用于自定义错误消息，`groups`指定验证时应用的组，`payload`可能包含额外的数据，以及可选的约束特定参数。 - 示例章节展示了如何在代码中实际使用这些注解，并组合多个相同类型的约束或进行约束的组合。 3. **验证实施**: - Spring提供了一个`ConstraintValidatorFactory`，用于创建和管理`ConstraintValidator`实例，这些验证器实现了具体约束的验证逻辑。 - 通过实例化`ConstraintValidator`并调用其`isValid`方法，可以在对象实例验证过程中检查特定字段是否符合约束条件。 4. **验证过程**: - 要进行验证，类或对象需满足一定的要求，例如，验证方法需要在公共访问级别，且遵循特定的生命周期规则。 - 约束声明通常放在类级别的元数据中，也可以通过继承接口或通过父类来复用验证逻辑。 - 集群验证（Graph validation）支持复杂的数据结构，如对象图中的相互依赖关系。 5. **组和组序列**: - 分组验证允许开发者定义一组相关的验证规则，以便按需组合或单独应用。组继承和组序列机制使得规则组织更加灵活。 - 红色重定义部分可能涉及对已有的组或顺序进行扩展或定制，以适应特定场景的验证需求。 Spring的JSR-303帮助文档为开发者提供了一套完整的工具，使他们能够利用Java Bean约束规范在Spring项目中实现对象的自我校验，从而提高代码质量、减少错误和异常，提升用户体验。通过遵循文档中的指南，开发者可以更好地理解和使用这一强大的功能。

is equivalent to

@FrenchZipcode

if @FrenchZipcode is defined as

@Pattern(regexp="[0-9]*")

@Size(min=9, max=9, message="Zipcode should be of size {max}")

@Constraint(validatedBy = FrenchZipcodeValidator.class)

@Documented

@Target({ METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER })

@Retention(RUNTIME)

public @interface FrenchZipcode {

String message() default "Wrong zipcode";

Class<?>[] groups() default {};

Class<? extends Payload>[] payload() default {};

@Target({ METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER })

@Retention(RUNTIME)

@Documented

@interface List {

FrenchZipcode[] value();

}

If a constraint is used more than once as a composing constraint, the multi value constraints model as described in

Section 2.2 is used. To select a specific composing constraint, OverridesAttribute.constraintIndex is used. It

represents the constraint index in the value array. If index is undefined, the single constraint declaration is tar-

geted.

Example 2.11. Use of constraintIndex in @OverridesAttribute

@Pattern.List( {

@Pattern(regexp="[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}"), //email

@Pattern(regexp=".*?emmanuel.*?") //emmanuel

} )

@Constraint(validatedBy={})

@Documented

@Target({ METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER })

@Retention(RUNTIME)

public @interface EmmanuelsEmail {

String message() default "Not emmanuel's email";

@OverridesAttribute(constraint=Pattern.class, name="message", constraintIndex=0)

String emailMessage() default "Not an email";

@OverridesAttribute(constraint=Pattern.class, name="message", constraintIndex=1)

String emmanuelMessage() default "Not Emmanuel";

Class<?>[] groups() default {};

Class<? extends Payload>[] payload() default {};

@Target({ METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER })

@Retention(RUNTIME)

@Documented

@interface List {

EmmanuelsEmail[] value();

}

Constraint Definition

1.0 final 13

straints defined by the specification. The composing constraints are exposed through the Bean Validation metadata

API (Section 5.5). This metadata is particularly useful for third-party metadata consumers like persistence frame-

works generating database schemas (such as Java Persistence) or presentation frameworks.

2.4. Constraint validation implementation

A constraint validation implementation performs the validation of a given constraint annotation for a given type.

The implementation classes are specified by the validatedBy element of the @Constraint annotation that decor-

ates the constraint definition. The constraint validation implementation implements the ConstraintValidator in-

terface.

/**

* Defines the logic to validate a given constraint A

* for a given object type T.

* Implementations must comply to the following restriction:

* <ul>

* <li>T must resolve to a non parameterized type</li>

* <li>or generic parameters of T must be unbounded

* wildcard types</li>

* </ul>

* @author Emmanuel Bernard

* @author Hardy Ferentschik

public interface ConstraintValidator<A extends Annotation, T> {

/**

* Initialize the validator in preparation for isValid calls.

* The constraint annotation for a given constraint declaration

* is passed.

*

* This method is guaranteed to be called before any use of this instance for

* validation.

* @param constraintAnnotation annotation instance for a given constraint declaration

void initialize(A constraintAnnotation);

/**

* Implement the validation logic.

* The state of <code>value</code> must not be altered.

* This method can be accessed concurrently, thread-safety must be ensured

* by the implementation.

* @param value object to validate

* @param context context in which the constraint is evaluated

* @return false if <code>value</code> does not pass the constraint

boolean isValid(T value, ConstraintValidatorContext context);

}

Some restrictions apply on the generic type T (used in the isValid method). T must

• resolve to a non parameterized type (i.e. because the type is not using generics or because the raw type is used

instead of the generic version)

• or generic parameters of T must be unbounded wildcard types (i.e. <?>)

Constraint Definition

1.0 final 15

Example 2.12 shows some examples of valid definitions.

Example 2.12. Valid ConstraintValidator definitions

//String is not making use of generics

public class SizeValidatorForString implements<Size, String> {...}

//Collection uses generics but the raw type is used

public class SizeValidatorForCollection implements<Size, Collection> {...}

//Collection uses generics and unbounded windcard type

public class SizeValidatorForCollection implements<Size, Collection<?>> {...}

And some invalid definitions in Example 2.13.

Example 2.13. Invalid ConstraintValidator definitions

//parameterized type

public class SizeValidatorForString implements<Size, Collection<String>> {...}

//parameterized type using bounded wildcard

public class SizeValidatorForCollection implements<Size, Collection<? extends Address>> {...}

Note

This restriction is not a theoretical limitation and a future version of the specification will likely allow it.

The life cycle of a constraint validation implementation instance is undefined. Compliant implementations are al-

lowed to cache ConstraintValidator instances retrieved from the ConstraintValidatorFactory.

The initialize method is called by the Bean validation provider prior to any use of the constraint implementation.

The isValid method is evaluated by the Bean Validation provider each time a given value is validated. It returns

false if the value is not valid, true otherwise. isValid implementations must be thread-safe.

If the property is of an unanticipated type, an UnexpectedTypeException is raised. ConstraintValidator imple-

mentations raise this exception themselves if they receive an unsupported type. However, constraint designers are

encouraged to make use of specialized ConstraintValidator implementations and delegate the type resolution to

the Bean Validation provider (see the type matching algorithm described in Section 3.5.3).

If an exception occurs either in the initialize or isValid method, the runtime exception is wrapped into a Valid-

ationException by the Bean Validation engine.

The constraint validation implementation is not allowed to change the state of the value passed to isValid.

Note

While not mandatory, it is considered a good practice to split the core constraint validation from the not

null constraint validation (for example, an @Email constraint will return true on a null object, i.e. will not

take care of the @NotNull validation)

Constraint Definition

1.0 final 16

null can have multiple meanings but is commonly used to express that a value does not make sense, is not

available or is simply unknown. Those constraints on the value are orthogonal in most cases to other con-

straints. For example a String, if present, must be an email but can be null. Separating both concerns is a

good practice.

The ConstraintValidatorContext object passed to the isValid method carries information and operations avail-

able in the context the constraint is validated to.

/**

* Provide contextual data and operation when applying a given constraint validator.

* At least one <code>ConstraintViolation</code> must be defined (either the default one,

* of if the default <code>ConstraintViolation</code> is disabled, a custom one).

* @author Emmanuel Bernard

public interface ConstraintValidatorContext {

/**

* Disable the default <code>ConstraintViolation</code> object generation (which

* is using the message template declared on the constraint).

* Useful to set a different violation message or generate a <code>ConstraintViolation</Code>

* based on a different property.

void disableDefaultConstraintViolation();

/**

* @return the current uninterpolated default message.

String getDefaultConstraintMessageTemplate();

/**

* Return an constraint violation builder building an violation report

* allowing to optionally associate it to a sub path.

* The violation message will be interpolated.

*

* To create the <code>ConstraintViolation</code>, one must call either one of

* the #addConstraintViolation() methods available in one of the

* interfaces of the fluent API.

* If another method is called after #addConstraintViolation() on

* <code>ConstraintViolationBuilder</code> or any of its associated nested interfaces

* an <code>IllegalStateException</code> is raised.

*

* If <code>isValid<code> returns <code>false</code>, a <code>ConstraintViolation</code>

* object will be built per ConstraintViolation report including the default one (unless

* {@link #disableDefaultConstraintViolation()} has been called).

*

* <code>ConstraintViolation</code> objects generated from such a call

* contain the same contextual information (root bean, path and so on) unless

* the path has been overriden.

*

* To create a different <code>ConstraintViolation</code>, a new constraint violation builder

* has to be retrieved from <code>ConstraintValidatorContext</code>

* Here are a few usage examples:

* <pre>

* {@code

* // create new violation report with the default path the constraint is located on

* context.buildConstraintViolationWithTemplate( "way too long" )

* .addConstraintViolation();

* // create new violation report in the "street" subnode of the default path

* //the constraint is located on

* context.buildConstraintViolationWithTemplate( "way too long" )

* .addNode( "street" )

Constraint Definition

1.0 final 17

剩余142页未读，继续阅读

sinat_14963997

粉丝: 0
资源: 1

Spring集成JSR-303 BeanValidation详解与约束实现

JSR303Test.zip

jsr305-3.0.2-API文档-中英对照版.zip

jsr303校验.txt

SpringMVC利用JSR-303进行服务端数据校验深度解析

spring-framework-5.0 中文文档PDF

JSR-268

Spring-framework-reference文档集合.zip

JSR303 jar包 文档

NotificationPortlet：在uPortal中实现通知的JSR-286 Portlet

spring-3.1.0中文版api帮助文档

最新资源

JSR303 jar包文档