AspNetCore.Docs/aspnetcore/mvc/advanced/custom-model-binding.md

8.7 KiB

title author description ms.author ms.date uid
Custom Model Binding in ASP.NET Core ardalis Learn how model binding allows controller actions to work directly with model types in ASP.NET Core. riande 04/10/2017 mvc/advanced/custom-model-binding

Custom Model Binding in ASP.NET Core

By Steve Smith

Model binding allows controller actions to work directly with model types (passed in as method arguments), rather than HTTP requests. Mapping between incoming request data and application models is handled by model binders. Developers can extend the built-in model binding functionality by implementing custom model binders (though typically, you don't need to write your own provider).

View or download sample from GitHub

Default model binder limitations

The default model binders support most of the common .NET Core data types and should meet most developers` needs. They expect to bind text-based input from the request directly to model types. You might need to transform the input prior to binding it. For example, when you have a key that can be used to look up model data. You can use a custom model binder to fetch data based on the key.

Model binding review

Model binding uses specific definitions for the types it operates on. A simple type is converted from a single string in the input. A complex type is converted from multiple input values. The framework determines the difference based on the existence of a TypeConverter. We recommended you create a type converter if you have a simple string -> SomeType mapping that doesn't require external resources.

Before creating your own custom model binder, it's worth reviewing how existing model binders are implemented. Consider the ByteArrayModelBinder which can be used to convert base64-encoded strings into byte arrays. The byte arrays are often stored as files or database BLOB fields.

Working with the ByteArrayModelBinder

Base64-encoded strings can be used to represent binary data. For example, the following image can be encoded as a string.

dotnet bot

A small portion of the encoded string is shown in the following image:

dotnet bot encoded

Follow the instructions in the sample's README to convert the base64-encoded string into a file.

ASP.NET Core MVC can take a base64-encoded string and use a ByteArrayModelBinder to convert it into a byte array. The ByteArrayModelBinderProvider which implements IModelBinderProvider maps byte[] arguments to ByteArrayModelBinder:

public IModelBinder GetBinder(ModelBinderProviderContext context)
{
    if (context == null)
    {
        throw new ArgumentNullException(nameof(context));
    }

    if (context.Metadata.ModelType == typeof(byte[]))
    {
        return new ByteArrayModelBinder();
    }

    return null;
}

When creating your own custom model binder, you can implement your own IModelBinderProvider type, or use the ModelBinderAttribute.

The following example shows how to use ByteArrayModelBinder to convert a base64-encoded string to a byte[] and save the result to a file:

[!code-csharp]

You can POST a base64-encoded string to this api method using a tool like Postman:

postman

As long as the binder can bind request data to appropriately named properties or arguments, model binding will succeed. The following example shows how to use ByteArrayModelBinder with a view model:

[!code-csharp]

Custom model binder sample

In this section we'll implement a custom model binder that:

  • Converts incoming request data into strongly typed key arguments.
  • Uses Entity Framework Core to fetch the associated entity.
  • Passes the associated entity as an argument to the action method.

The following sample uses the ModelBinder attribute on the Author model:

[!code-csharp]

In the preceding code, the ModelBinder attribute specifies the type of IModelBinder that should be used to bind Author action parameters.

The AuthorEntityBinder is used to bind an Author parameter by fetching the entity from a data source using Entity Framework Core and an authorId:

[!code-csharp]

The following code shows how to use the AuthorEntityBinder in an action method:

[!code-csharp]

The ModelBinder attribute can be used to apply the AuthorEntityBinder to parameters that don't use default conventions:

[!code-csharp]

In this example, since the name of the argument isn't the default authorId, it's specified on the parameter using the ModelBinder attribute. Note that both the controller and action method are simplified compared to looking up the entity in the action method. The logic to fetch the author using Entity Framework Core is moved to the model binder. This can be a considerable simplification when you have several methods that bind to the Author model, and can help you to follow the DRY principle.

You can apply the ModelBinder attribute to individual model properties (such as on a viewmodel) or to action method parameters to specify a certain model binder or model name for just that type or action.

Implementing a ModelBinderProvider

Instead of applying an attribute, you can implement IModelBinderProvider. This is how the built-in framework binders are implemented. When you specify the type your binder operates on, you specify the type of argument it produces, not the input your binder accepts. The following binder provider works with the AuthorEntityBinder. When it's added to MVC's collection of providers, you don't need to use the ModelBinder attribute on Author or Author typed parameters.

[!code-csharp]

Note: The preceding code returns a BinderTypeModelBinder. BinderTypeModelBinder acts as a factory for model binders and provides dependency injection (DI). The AuthorEntityBinder requires DI to access EF Core. Use BinderTypeModelBinder if your model binder requires services from DI.

To use a custom model binder provider, add it in ConfigureServices:

[!code-csharp]

When evaluating model binders, the collection of providers is examined in order. The first provider that returns a binder is used.

The following image shows the default model binders from the debugger.

default model binders

Adding your provider to the end of the collection may result in a built-in model binder being called before your custom binder has a chance. In this example, the custom provider is added to the beginning of the collection to ensure it's used for Author action arguments.

[!code-csharp]

Recommendations and best practices

Custom model binders:

  • Shouldn't attempt to set status codes or return results (for example, 404 Not Found). If model binding fails, an action filter or logic within the action method itself should handle the failure.
  • Are most useful for eliminating repetitive code and cross-cutting concerns from action methods.
  • Typically shouldn't be used to convert a string into a custom type, a TypeConverter is usually a better option.