Server validation with a validator component upgrade

[guardrex]

Fixes #36051

Ondřej ... Per your suggestion in #35972, the general idea is to replace the MVC controller with a Minimal API validation, including the unified validation experience. I'm getting close (see "Problem at the moment" below).

To simplify the section, the content is versioned into >=10.0, >=8.0/<10.0, and <8.0 blocks. I think we only need to focus on the new guidance in the >=10.0 coverage at the top of the section. I haven't received any complaints (or death threats 💀😨😆) from our readers on our MVC controller-based guidance.

Problem at the moment

What's on the PR works for server-side BWA processing (ServerFormValidator), but this approach is failing to get the ValidationProblemDetails into the validation message store in the CustomValidator component when running client-side. It's not an artifact of prerendering. There's something else going on. I'll work with it some more on Monday.

---

Internal previews

📄 File	🔗 Preview link
aspnetcore/blazor/forms/validation.md	aspnetcore/blazor/forms/validation

[Copilot]

Pull request overview

Updates the “Server validation with a validator component” guidance in validation.md to introduce a .NET 10+ flow that uses a Minimal API-based validation endpoint and splits the content into versioned blocks.

Changes:

• Adds a new >= aspnetcore-10.0 section demonstrating server validation via a Minimal API and a client/server validator abstraction.
• Reorganizes the existing guidance into >=8.0/<10.0 and <8.0 moniker blocks.
• Introduces new sample code and updated narrative around client + server validation responsibilities.

[oroztocil]

Hi @guardrex, sorry for not getting to this sooner. I did read through the whole PR but a first general comment is that by using a validated Minimal API endpoint (instead of a MVC controller) I meant using the built-in validation feature we added in .NET 10 that you enable simply by calling builder.Services.AddValidation(). A built-in filter in the request pipeline then validates all the DataAnnotations attributes on the request parameters automatically (including nested properties of model classes).

That should significantly simplify the examples because you don't need to build and register any custom validators (the IFormValidator types in your example), you don't need to create ProblemDetails manually, etc.

[guardrex]

@oroztocil ... No worries on the delay. I've needed the time to work on this approach.

[UPDATE (5/12): I see that you did a Community Standup with Dan a few weeks ago. I'll watch that and roll concepts into the coverage from your remarks there.]

This is a complicated subject to even discuss here ... lots of moving parts. I'll try to break it down on how I'm thinking about it, and then you can tell me what I'm getting wrong or missing .........

I have the built-in Data Annotations (DA) validation feature (builder.Services.AddValidation()) included where the approach in this section states the following ...

Also in the `Program` file of the Minimal API, register [built-in validation services](xref:fundamentals/minimal-apis#validation-support-in-minimal-apis):

```csharp
builder.Services.AddValidation();
```

Built-in validation automatically intercepts the endpoint request and validates the types that the endpoint receives. If the model fails validation, the framework returns a *400 - Bad Request* response with error details without executing the endpoint's code.

The link goes here ...

https://learn.microsoft.com/en-us/aspnet/core/fundamentals/minimal-apis?view=aspnetcore-10.0#enable-built-in-validation-support-for-minimal-apis

For one thing, that's not enough information even in this section. It should state that it's specifically DA validation that takes place. It also doesn't include links to the additional content that we placed at .NET 10's release on Nested objects and collection types and Use validation models from a different assembly. I'll need to work on those remarks in this section.

Beyond that, I realize now that this isn't enough coverage in Blazor's Validation article on the built-in validation in general. I now think that there should be additional coverage on the built-in validation either in the introductory remarks of this article or in a new section near the top of the article.

But for your remark ...

That should significantly simplify the examples because you don't need to build and register any custom validators (the IFormValidator types in your example), you don't need to create ProblemDetails manually, etc.

Don't we still need all of this infrastructure for truly custom business logic validation that can't be easily addressed by DA validation and where a custom ValidationAttribute isn't what the dev wants to use? For example ...

• When one or more server-side database queries are needed to process validation on a form field.
• When several field values must be analyzed in order to process validation on a form field.
• When complex operations must be performed on the user's input from a form field to process validation on that field.

... cases like those. In this example, the custom logic is to see what's in another field to determine if a different form field should pass validation.

Even if that's correct ......

Making matters worse in the global Auto BWA case, the server and client form validation services all need wiring up and ProblemDetails have to go through the server app from the client when running on the client. Downstream API's CallApiForUserAsync call has been a real PITA because the code ...

var response = await downstreamApi.CallApiForUserAsync<StarshipModel, ValidationProblemDetails>(...);

... hasn't been behaving. It's either throwing an exception in some cases or I don't get back the expected ValidationProblemDetails from it ... response is null ... that's what I'm fighting with at the moment.

Anyway ... setting my current coding troubles aside for a minute ... do you agree that we still need a section like this for custom/complex validation that DA can't handle easily, where the dev wants to write code into the Minimal API to manually determine if a field should be validated?