@Valid Cascaded Validation in Java

`@Valid` tells the Bean Validation provider to continue validation into a nested object instead of stopping at the containing object. This is commonly used when a DTO contains another DTO whose fields have their own constraints.

Bean Validation normally checks constraints declared on the object being validated. When a field, parameter, or collection element is annotated with `@Valid`, validation is cascaded to the referenced object, so its own constraints are evaluated as well.

For example, an `OrderRequest` may contain a `Customer` object. If `Customer.name` has `@NotBlank`, placing `@Valid` on the `customer` field causes that nested `name` constraint to be checked when the `OrderRequest` is validated.

Cascaded validation can also apply to container elements. For example, `List<@Valid Address>` tells the validator to validate each `Address` object in the list. `@Valid` does not itself define a constraint such as "must not be null"; use constraints such as `@NotNull` when the nested reference itself is required.

In a typical Spring application, `@Valid` is often placed on a controller method parameter such as `@RequestBody @Valid OrderRequest request`. If the request contains nested objects marked with `@Valid`, their constraints are traversed during the same validation operation.

Key points

• `@Valid` enables recursive validation of nested objects.
• It cascades validation but does not itself require the nested reference to be non-null.
• Nested DTO fields must declare their own constraints such as `@NotBlank` or `@Size`.
• `@Valid` can be used with container elements such as `List<@Valid Address>`.
• Use `@NotNull` separately when the nested object itself is required.

Interview questions

What does `@Valid` do in Bean Validation?

`@Valid` enables cascaded validation for the annotated object or container element. When the parent object is validated, the validator also evaluates constraints declared on the nested object. It is useful for DTOs containing other DTOs. It does not replace constraints such as `@NotNull`.

What is the difference between `@Valid` and `@NotNull`?

`@NotNull` verifies that a value is not null. `@Valid` tells the validator to continue into a referenced object and evaluate its constraints. If both requirements matter, both annotations can be used. They solve different validation problems.

How would you validate a list of nested DTOs?

The collection can use container-element cascading, for example `List<@Valid Address> addresses`. During validation, each `Address` element is traversed and its declared constraints are evaluated. If the collection itself must exist, a separate `@NotNull` constraint can be placed on the collection field. Additional constraints such as `@Size` can enforce collection-level requirements.

What happens when a nested DTO has `@NotBlank` but the parent field lacks `@Valid`?

The nested object's `@NotBlank` constraint is not reached through ordinary cascaded validation of the parent. The parent needs cascade metadata, such as `@Valid`, on that association. Once cascading is enabled, validation traverses the association and evaluates the nested constraint. This separation lets applications control which object relationships participate in validation.

Can `@Valid` be combined with validation groups?

Yes. Cascaded validation and validation groups address different concerns and can be used together. Groups determine which constraints are active for a validation operation, while `@Valid` enables traversal into associated objects. Group conversion can also be configured for cascaded associations when the nested object should be validated using a different group.