Open neistow opened 3 years ago
I can't duplicate the exception-scenario mentioned in "Expected behaviour". May you post a sample project as a ZIP-file or the stack trace from the exception? When I use [FromBody]
and submit Request
, dto.someNestedDto
is initialized with default-values for all properties. When I don't pass the property in the request, dto.someNestedDto
is null
.
Hi @billbogaiv,
Was a bit busy this month but today we had again an issue with Hybird model binding attribute so I decided that today is the day to come back to old problems so I've made an example repo where you can reproduce issue.
Check the following screenshot which illustrates the problem:
[PUT] https://localhost:5001/api/example/
{
"test": [1,2,3],
"model": 10
}
Also there is a weird and confusing behavior with FluentValidaton, for example if we have the following validator defined for ExampleModel
and we pass the wrong type e.g int
instead of object
the response will have a misleading error that regards another property which is valid.
public class ExampleModelValidator : AbstractValidator<ExampleModel>
{
public ExampleModelValidator()
{
RuleFor(c => c.Test).NotEmpty();
RuleFor(c => c.Model.Value).GreaterThanOrEqualTo(1).When(c => c.Model != null);
}
}
The behavior I get when I'm using [FromBody]
and which is the correct behavior in my opinion:
Thanks for the sample repo. I've identified a couple issues and should be able to get an update pushed soon.
BodyModelBinder
.int[]
.Regarding the null
in the response, using [FromHybrid]
on its own won't work. You still need to register the service in Startup
:
public void ConfigureServices(IServiceCollection services)
{
services
.AddControllers()
.AddHybridModelBinder();
}
AddHybridModelBinder
works with any IMvcBuilder
-type.
Registering HybridModelBinder
in the services won't help. I've updated sample repo so you can test it and ensure that even with HybridModelBinder
registered in services there is still null when passing a wrong type. While [FromBody]
return a parse exception.
The forthcoming update will fix those problems, but without registering the service, even submitting a request like the following won't trigger the expected binding:
{
"model": { "value": 1 }
}
Using attributes like [FromHybrid]
and [FromBody]
only specifies a binding-source to use. There still needs to be a registered binding-provider which uses that source. ASP.NET won't throw an error if the binder isn't registered and you'll continue to see null
s in the response.
services.AddControllers()
registers the necessary binders to use something like [FromBody]
.
Hi @billbogaiv any news on this update? We've run into a similar issue and wanted to know if this update was on the horizon. It's a new year and everyone is busy so I get it if this isn't happening anytime soon. Only asking to inform our decisions going forward.
I've stumbled upon an odd behaviour with hybrid model binding. Consider this example:
Model:
Controller endpoint:
Request:
In the request property "someNestedDto" has INTENTIONALLY a wrong type.
Behaviour: dto that comes to my controller method has empty fields with default values.
Expected behaviour: parse error. If this happens with [FromBody] attribute applied to MyDto, then a parse exception will be raised.
As for me such errors shouldn't pass silently.