Here we can see, “Adding a Razor Pages ModelBindingProvider in ASP.NET Core”
‘MvcOptions’ is used instead of ‘AddMvc()’.
As of.NET Core 3.1, Microsoft’s official documentation on adding custom model binding providers to convert between (usually) a string and a custom type for sophisticated model binding in ASP.NET Core is as follows:
- Create an IModelBinder for your class and use [ModelBinder(BinderType = typeof(MyModelEntityBinder)] to decorate each and every binding site, for example,
public async TaskIActionResult> OnPost([ModelBinder(BinderType = typeof(MyModelEntityBinder)]) MyModel model),
which gives the runtime the type information it needs to instantiate the model binding provider and convert the input to a
- Create an IModelBinderProvider class and register it with the ASP.NET Core host to supply type information in advance (once and for all), so you may use the barebones and considerably shorter decorator at each model binding point instead:
public async Task<IActionResult> OnPost([ModelBinder] MyModel model)
The latter is more easier on the eyes and substantially less prone to errors. Where, on the other hand, does type registration take place? The following is the recommendation in Startup.cs, according to the attached documentation:
services.AddMvc(options =>
{
// add custom binder to beginning of collection
options.ModelBinderProviders.Insert(0, new MyModelBindingProvider());
});
This is quite straightforward and to the point, except that it necessitates importing the MVC dependencies and components, which may not be desired in terms of overhead if you’re working on a new project using Razor Pages solely.
Unfortunately, the default Razor Page’s options configurator lacks an equivalent ModelBinderProviders property, and the RazorPagesOptions object supplied by the AddRazorPages() extension function lacks any such feature as well.
However, we can directly apply the AddMvcOptions (options =>…) extension method on the IServiceCollection to setup the ModelBinderProviders collection without having to call AddMvc() in our project:
services.AddRazorPages()
.AddMvcOptions(options =>
{
options.ModelBinderProviders.Add(new MyModelBindingProvider());
}
AddMvcOptions is basically just syntactic sugar that hides the dependency injection while explicitly supplying the types in this situation. When the (Razor Pages) runtime needs the model binding settings, it simply gets a reference to the globally-injected MvcOptions returned by the setup action, from which it can access the ModelBinderProviders, which is now equipped with our model’s custom binding provider… Except it’s even more dogfooded, as you can inject the IModelBinderProvider right into the IServiceCollection using Razor Pages and have it resolved at runtime anyway:
services.AddRazorPages();
services.AddSingleton<IModelBinderProvider>(new MyModelBindingProvider());
I’m not sure if it works in real MVC apps. However, I suppose there are scenarios where accessing the ModelBinderProviders instance directly rather than using dependency injection to query the binding provider instance would be preferable.
More crucially, IModelProvider is not a generic interface. For example, its type data contains no indication of the types of models it can resolve: this is one of the reasons why the official documentation recommends using ModelBinderProviders with the first code sample.
ModelBinderProviders uses Insert(0,…) instead of the second.
Because Add(…) places your custom model binding provider at the top of the providers’ list, whereas neither of the other options does.
There is no explicit precedence or type specificity in Add(…) and AddSingletonIModelBindingProvider>, therefore a different model binding provider could be chosen over yours.
However, this also hints at something else: performance. As previously stated, an IModelBinderProvider declaration contains no information about the available kinds. Rather, each registered provider must be called (in some sequence) to verify if it matches the binding site, which is why a typical IModelBinderProvider implementation will look like this:
public IModelBinder? GetBinder(ModelBinderProviderContext context)
{
if (context?.Metadata.ModelType == typeof(Ulid))
{
return new BinderTypeModelBinder(typeof(UlidEntityBinder));
}
return null;
}
This may rapidly test for supported types and error out. Still, a bad implementation may easily do more work (and possibly heap allocations!) before failing to provide a converter and returning null. Even if it doesn’t, you never know how many model binders will be invoked before yours or how long it will take to invoke them all. As a result, if you’re only doing a simple text-to-object conversion with no sophisticated binding needs, a TypeConverter class is recommended instead.
Conclusion
I hope you found this information helpful. Please fill out the form below if you have any questions or comments.
User Questions
1. In Entity Framework crud, how do you add a razor page?
Right-click the Pages/Students folder in Solution Explorer and choose Add > New Scaffolded Item. In the dialog box for adding a new scaffold item, type: Select Installed > Common > Razor Pages from the left tab. Then, using Entity Framework (CRUD) > ADD, select Razor Pages.
2. Is it better to utilize MVC or Razor pages?
MVC is a good choice for apps with many dynamic server views, single-page apps, REST APIs, and AJAX calls. Razor Pages are ideal for creating simple read-only or data-input pages. MVC has recently become popular for online applications in almost all programming languages.
3. Is it true that Razor Pages is a framework?
ASP.NET,.NET 5, Razor Pages is a server-side, page-focused framework that allows you to create dynamic, data-driven websites with a clear separation of concerns. For cross-platform server-side HTML production, Razor Pages is the recommended framework.
4. ASP.NET Core MVC Model Binding : r/dotnet – Reddit
5. How would you set up this ASP.NET Core project given the following restraints…
How would you set up this ASP.NET Core project given the following restraints… from dotnet