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 :

http://www.mydomain.com/date?day=1&month=2&year=1985

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 :

public class MyViewModel
{
	public DateTime MyDate { get; set; }
}

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

public class MyViewModelBinder : IModelBinder
{
	public Task BindModelAsync(ModelBindingContext bindingContext)
	{
		var day = 0; 
		var month = 0; 
		var year = 0;

		if(!int.TryParse(bindingContext.ActionContext.HttpContext.Request.Query["day"], out day) || 
		!int.TryParse(bindingContext.ActionContext.HttpContext.Request.Query["month"], out month) || 
		!int.TryParse(bindingContext.ActionContext.HttpContext.Request.Query["year"], out year))
		{
			return Task.CompletedTask;
		}

		var result = new MyViewModel
		{
			MyDate = new DateTime(year, month, day)
		};

		bindingContext.Result = ModelBindingResult.Success(result);
		return Task.CompletedTask;
	}
}

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 ASP.NET core, we also need to use a provider. A provider tells ASP.NET 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 :

public class MyViewModelBinderProvider : IModelBinderProvider
{
	public IModelBinder GetBinder(ModelBinderProviderContext context)
	{
		if (context.Metadata.ModelType == typeof(MyViewModel))
			return new MyViewModelBinder();

		return null;
	}
}

Simple!

Next we just need to let ASP.NET Core know that we have a model binder ready for use. You do this in your startup.cs file in the ConfigureServices method. Note that we “insert” our model binder provider at the start of the list. This is because it’s first in first served, so we want to make sure that our modelbinder is always the first to run if possible.

public void ConfigureServices(IServiceCollection services)
{
	// Add framework services.
	services.AddMvc(config =>
		config.ModelBinderProviders.Insert(0, new MyViewModelBinderProvider())
	);
}

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

[HttpGet("")]
public string Get(MyViewModel viewModel)
{
	if (viewModel == null)
		return "Woops. We received null!";
	return $"The date you sent was {viewModel.MyDate}";
}

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

The date you sent was 1/02/1985 12:00:00 AM

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.

If you’ve been using ASP.NET for any length of time you’ve probably had to build your own implementation of the CustomConfiguration class or had to implement the IConfigurationSectionHandler. This usually included writing out each configuration element and how to read it from the XML (Including conversions/casts). What a pain!

DotNetCore takes a much simpler approach to custom configurations. There are two main ways to use it, one that uses an Options class from .net Core, and one that uses simple POCOs.

Method 1 : The Options Class

This way is the most common example you’ll see out there. It uses the Options class built into .net core and is pretty easy to get going. Because it drags around the “options” class, it actually isn’t my preferred method. I much prefer simple POCO’s. If you do too, then skip to Option 2 below. Otherwise read on!

Imagine you have an appSettings.json like so :

{
  "myConfiguration": {
    "myProperty": true 
  }
}

You would create a simple configuration class like the following in your project :

public class MyConfiguration
{
    public bool MyProperty { get; set; }
}

Notice how in the above we don’t have to inherit or implement any interfaces/classes. It’s a simple POCO that doesn’t require any additional references.

Now in your startup.cs, you have the following :

public class Startup
{
	public Startup(IHostingEnvironment env)
	{
		var builder = new ConfigurationBuilder()
			.SetBasePath(env.ContentRootPath)
			.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
			.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true)
			.AddEnvironmentVariables();
		Configuration = builder.Build();
	}

	public IConfigurationRoot Configuration { get; }

	public void ConfigureServices(IServiceCollection services)
	{
		services.Configure<MyConfiguration>(Configuration.GetSection("myConfiguration"));
	}
}

Notice in the ConfigureServices method we add a configuration to our services. This is all it takes

Next we go to any controller and we can reference IOptions<MyConfiguration> to access our custom configuration.

public class ValuesController : Controller
{
	private readonly MyConfiguration _myConfiguration;

	public ValuesController(IOptions<MyConfiguration> myConfiguration)
	{
		_myConfiguration = myConfiguration.Value;
	}
}

Simple right? But from the above you can probably pick why this isn’t my preferred method. We drag along this IOptions interface but pull the value from it immediately. If we could inject our POCO class that holds our configuration then we don’t need to drag around the IOptions interface. Let’s take a look at that.

Method 2 : Get Configuration Poco

Utilizing what we already have above, we just need to change a couple of lines. In our startup.cs we need to change the call to configure to one that just binds a POCO :

public void ConfigureServices(IServiceCollection services)
{
	//services.Configure<MyConfiguration>(Configuration.GetSection("myConfiguration"));
	services.AddSingleton(Configuration.GetSection("myConfiguration").Get<MyConfiguration>());
}

A couple of notes :

• You previously were able to call “AddInstance” on an IServiceCollection. This was removed to just allow “AddSingleton”, which really is one and the same anyway.
• Previous versions of .net Core (Pre 1.1) did not allow a call to “Get”, instead you had to do a call to “bind”. This was an added annoyance as you had to instantiate an empty class first. If you are on an early version and unable to upgrade, do the below.

Bind option (Pre ASP.NET core 1.1) :

public void ConfigureServices(IServiceCollection services)
{
	//services.Configure<MyConfiguration>(Configuration.GetSection("myConfiguration"));
	MyConfiguration configuration = new MyConfiguration();
	Configuration.GetSection("myConfiguration").Bind(configuration);
	services.AddSingleton(configuration);
}

Then if you go to your class, you only need to ask for your POCO, not the IOptions. Like so :

public class ValuesController : Controller
{
	private readonly MyConfiguration _myConfiguration;

	public ValuesController(MyConfiguration myConfiguration)
	{
		_myConfiguration = myConfiguration;
	}
}

Best Practice

If you go with Method 2. A good habit to get into is to always inject in an interface instead of your concrete class. This allows for easier mocking when doing unit testing, and it better follows the Dependency Inversion principle which is that you depend on abstractions.