Description
Background and Motivation
This is a proposal to add DateOnly and TimeOnly to the list of supported simple types for MVC model binding. Adding this functionality will allow ASP.NET Core and Blazor developers a clean and safe way to convert form/string data into the DateOnly and TimeOnly types.
While an avenue to this behavior currently exists since the addition of the TryParse model binder, streamlining this experience with new model binders would make these types easier to use and less prone to bugs/error. There has been community request for these types to have built-in model binders since their addition in .NET 6.
Proposed API
This propsal would add the following API to the existing Microsoft.AspNetCore.MvcModelBinding.Binders namespace:
namespace Microsoft.AspNetCore.MvcModelBinding.Binders
{
public class DateOnlyModelBinder
{
public DateOnlyModelBinder(DateTimeStyles supportedStyles, ILoggerFactory loggerFactory);
public Task BindModelAsync(ModelBindingContext bindingContext);
}
public class DateOnlyModelBinderProvider
{
public IModelBinder? GetBinder(ModelBinderProviderContext context);
}
public class TimeOnlyModelBinder
{
public TimeOnlyModelBinder(DateTimeStyles supportedStyles, ILoggerFactory loggerFactory);
public Task BindModelAsync(ModelBindingContext bindingContext);
}
public class TimeOnlyModelBinderProvider
{
public IModelBinder? GetBinder(ModelBinderProviderContext context);
}
}These changes are also available in this PR.
Usage Examples
[HttpGet("{date}")]
public ActionResult GetDateAndTime(DateOnly date, TimeOnly time)
{
// Do stuff
}Alternative Designs
Since the model binders + providers are so similar to those for DateTime, @TanayParikh raised the question of whether it would be better to generalize the model binding for DateTime, DateOnly, and TimeOnly. This would allow maintenance and refactoring to be much cleaner and efficient for these very similar types. I think there's merit to this idea particularly at the model binder level (with each having their own provider) but since this would modify an existing public API, I am concerned about raising breaking changes.
Risks
The addition of these new model binder providers to MVC option configuration (see here) would slightly increase the size of the provider list in the MVC configuration class but the expected difference is minimal.