Open julealgon opened 1 year ago
@julealgon Actually, I had a rough design for a similar situation. Correct me at https://github.com/OData/AspNetCoreOData/blob/main/src/Microsoft.AspNetCore.OData/Formatter/FromODataBodyAttribute.cs
It's not finished yet until I have more clear customer usages. Any thoughts?
@julealgon Actually, I had a rough design for a similar situation. Correct me at https://github.com/OData/AspNetCoreOData/blob/main/src/Microsoft.AspNetCore.OData/Formatter/FromODataBodyAttribute.cs
It's not finished yet until I have more clear customer usages. Any thoughts?
That's certainly a start right there!
Personally, I think it would be awesome if we found a way to do it without requiring a custom attribute or at least a way to default to that attribute for action complex type parameters similar to how standard MVC routes default to [FromBody]
for POST requests when using [ApiController]
.
I don't precisely know how the convention was created with [ApiController]
but would suggest looking into it to see if we could define a similar convention for OData actions.
Forgot to link this with the other issue were we discussed about it and I mentioned I'd open it:
@habex-ch FYI
Custom functions today are very cumbersome to use: they require the use of parameters that are bound to a custom dictionary-like structure,
ODataActionParameters
. The consumer then needs to read the parameters from this object to use them.This goes against standard MVC model binding which allows (and recommends) binding your parameters directly into a strongly typed model object that represent them.
I think adding native support in OData to bind the body of the action to an actual custom model (like MVC does) would make the framework vastly easier to use.
From the docs: https://learn.microsoft.com/en-us/odata/webapi-8/fundamentals/actions-functions#bound-action-1
Instead of:
We'd do:
This would naturally also open the door for standard validation using DataAnnotations or FluentValidation, making it much more seamless when coming from a normal MVC route.
When specifying the EDM for the function, I'm not entirely sure what would need to be done there, but maybe something that would generate the required EDM automatically based on the complex type could be achieved?
The
Parameter
method could identify that the type is not a primitive type, and apply the rules as needed (either transparently transform it into multipleParameter<primitiveType>
calls for each property, or just support this natively at the EDM level as well.