Custom Model Binders in Core

Custom Model Binders are a super helpful tool in “binding” a view model in unconventinal ways. There are a few reasons you may find yourself using a custom model binder.

  1. You are taking in values in seperated out fields, but want to combine them into a single object/struct.
  2. The model the front end is sending is actually nothing like the backend model, and neither side can change for some reason. (We’ve all been there!)
  3. You need to “Supplement” your model with outside data that isn’t coming in the payload (e.g. a cookie, a value from a database/config etc).

We will be focussing on the first reason as it’s the easiest to demonstrate. However once you have the hang of a custom model binder the possibilities really open up and there is no limit to what you can bind.

In our example, we are requesting a URL like the following :

This might happen if you have separated out select boxes for your dates for whatever reason. You end up with each portion of the date coming through individually. On the backend this can be a pain because we want to deal with a single Datetime object. We could receive all of these individually and build them up in the action, or we could “bind” them before it even reaches the action. Let’s see how.

First, we build our ViewModel of what we want to receive. In our case it’s a simple class with a single property :

Next we build a “ModelBinder” that inherits from IModelBinder. This might look like the following :

Notice that in this case we reach into the query string to read our values, but this could be from anywhere.

In the latest version of core, we also need to use a provider. A provider tells core when to use our custom binder. For us it’s very simple. If the model we are binding to is of type “MyViewModel” then use our binder. Of course this can be much more complicated and can even return different binders based on code within the provider. Our provider looks like the following :


Next we just need to let Core know that we have a model binder ready for use. You do this in your startup.cs file in the ConfigureServices method :

Finally, create your action in your controller that asks for “MyViewModel”. Something like the following :

And all going well, when you call your URL you should see :

As you can see, Model Binding really isn’t that hard. It may seem a bit overkill at first, but simply knowing it exists means that when that one time you actually need it comes up, you have it ready to use at your disposal.

Leave a Reply

Your email address will not be published. Required fields are marked *