Add async APIs to System.ComponentModel for type conversion and validation

[captainsafia]

The System.ComponentModel APIs are designed around synchronous patterns. This limits their use in modern applications where model binding, conversion, and validation frequently require asynchronous operations (database lookups, external service calls, async validation frameworks, etc.). As a result, developers must either block on async calls (leading to thread starvation and deadlocks) or duplicate logic outside the existing extensibility points.

We should consider first-class async support for these types to line up with validation support in frameworks like minimal APIs.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-componentmodel
See info in area-owners.md if you want to be subscribed.

[jeffhandley]

For validation, we can look at integrating INotifyDataErrorInfo. I suspect much of the pattern we used for async validation from RIA Services could still apply.

https://jeffhandley.com/2010-05-26/asyncvalidation-again

[777812]

@InterpolationStation

[ploeh]

What would be a use case for asynchronous validation?

[CoreDX9]

@ploeh

1. If I use IdentityCore for user system in ASP.NET Core, and I want to validate whether the username is in use. I need use UserManager‘s APIs, but UserManager only provide asynchronous methods. This is a real use case.
2. Validation model is core basic functions. We should not assume that developers will never write asynchronous code, or that external dependencies necessarily provide synchronous methods. Just like the previous example.

If the framework does not provide this feature, it will create serious obstacles for developers. With the popularization of asynchronous functionality, the risk of having to face asynchronous code will continue to rise. Calling asynchronous methods in synchronous code has an inevitable risk of deadlock. Frameworks should not deprive developers of their right to choose.

[ploeh]

1. If I use IdentityCore for user system in ASP.NET Core, and I want to validate whether the username is in use. I need use `UserManager`‘s APIs, but `UserManager` only provide asynchronous methods. This is a real use case.

Consider a custom block of 'validation' code that checks whether the user name is in use. It decides that it's not, and proceed under the assumption that all is good. Meanwhile, another session registers that username, invalidating the assumption.

Most asynchronous code inherently involve out-of-process operations that are subject to race conditions like the above. Is there another use case that doesn't suffer from this problem?

[CoreDX9]

@ploeh
The uniqueness constraint of the database is used to ensure that usernames are not duplicated. However, the verification function can prevent invalid operations in advance in most cases. It can reduce unnecessary jumps in self growing primary keys.

IdentityCore has a personal information protection feature that enables client data encryption. If this feature is used, custom code will no longer be applicable. More and more features are being developed entirely using asynchronous code, indicating an increasing likelihood of developers relying on asynchronous code.

Many application frameworks utilize the validation features of the core framework. But this feature is not out of the box. It requires developers to implement custom validation rules using custom code. We should assume that developers will inevitably write asynchronous code.

Calling asynchronous methods in synchronous code has an inevitable risk of deadlock. So validation features should provide a pure asynchronous path to ensure the elimination of deadlock risks.

ASP.NET Core MVC has built-in validation, but due to the lack of support for asynchronous, asynchronous validation cannot be elegantly integrated. Developers cannot fully enjoy the convenience provided by the validation system.

[ploeh]

[...] The uniqueness constraint of the database is used to ensure that usernames are not duplicated.

Indeed, some fall-back mechanism is required to catch 'validations' that turn out to be false positives. Sometimes you can rely on the "uniqueness constraint of the database", but since this is proposed to be a general-purpose framework API, you can't assume that any system behind an asynchronous API is a relational database. There may not be any automatic consistency mechanism in place, in which case it's up to the client developer to ensure consistency.

In such cases, you need to implement the fall-back mechanism anyway, implying that the effort of implementing the custom 'validation' may be wasted. Or, at best, it only acts as a filtering mechanism, but not as a correctness guarantee.

My concern is that the proposed capability will nudge developers to implement various 'validation' rules in this way. This is generally a problematic architectural design decision, because it gives programmers the wrong mental model of how the system works: One may think that a validated object represents an entity that has 'passed all checks', while in reality, any decision arrived at via an asynchronous API is only a snapshot.

I'm aware of all the implications of how async/await works in C#. My concern is not based on any lack of technical understanding; my concern is that this leads to poor architectural decisions. It's a footgun that I think should not be in the framework.

[CoreDX9]

@ploeh
EF Core will abandon support for synchronization methods in the future. If I need to use EF Core to retrieve the parameters for validation from the database, I cannot avoid calling asynchronous methods. In this case, the validation result of the asynchronous version is the final result.

There are many benefits to using EF Core for managing and interacting with databases. There are also many benefits to using a unified validation framework. I hope they can get along harmoniously.

FluentValidation supports asynchronous validation , but the basic validation framework does not support it. This also makes integration work full of challenges.