>前言

好久沒冒泡了，算起來估計(jì)有快半年沒更新博客了，估計(jì)是我第一次停更如此之久，人總有懶惰的時(shí)候，時(shí)間越長越懶惰，但是呢，不學(xué)又不行，持續(xù)的惰性是不行dei，要不然會(huì)被時(shí)光所拋棄，技術(shù)所淘汰，好吧，進(jìn)入今天的主題，本節(jié)內(nèi)容，我們來講講.NET Core當(dāng)中的模型綁定系統(tǒng)、模型綁定原理、自定義模型綁定、混合綁定、ApiController特性本質(zhì)，可能有些園友已經(jīng)看過，但是效果不太好哈，這篇是解釋最為詳細(xì)的一篇，建議已經(jīng)學(xué)過我發(fā)布課程的童鞋也看下，本篇內(nèi)容略長，請保持耐心，我只講你們會(huì)用到的或者說能夠?qū)W到東西的內(nèi)容。

模型綁定系統(tǒng)

對于模型綁定，.NET Core給我們提供了[BindRequired]、[BindNever]、[FromHeader]、[FromQuery]、[FromRoute]、[FromForm]、[FromServices]、[FromBody]等特性，[BindRequired]和[BindNever]翻譯成必須綁定，從不綁定我們稱之為行為綁定，而緊跟后面的五個(gè)From，翻譯成從哪里來，我們稱之為來源綁定，下面我們詳細(xì)介紹這兩種綁定類型，本節(jié)內(nèi)容使用版本.NET Core 2.2版本。

行為綁定

[BindRequired]表示參數(shù)的鍵必須要提供，但是并不關(guān)心參數(shù)的值是否為空，[BindNever]表示忽略對屬性的綁定，行為綁定看似很簡單，其實(shí)不然，待我娓娓道來，首先我們來看如下代碼片段。

public class Customer
 {
 [BindNever]
 public int Id { get; set; }
 }

 [Route("[controller]")]
 public class ModelBindController : Controller
 {
 [HttpPost]
 public IActionResult Post(Customer customer)
 {
  if (!ModelState.IsValid)
  {
  return BadRequest(ModelState);
  }
  return Ok();
 }
 }

上述我們定義了一個(gè)Customer類，然后類中的id字段通過[BindNever]特性進(jìn)行標(biāo)識，接下來我們一切都通過Postman來發(fā)出請求

當(dāng)我們?nèi)缟习l(fā)送請求時(shí)，響應(yīng)將返回狀態(tài)碼200成功且id沒有綁定上，符合我們的預(yù)期，其意思就是從不綁定屬性id，好接下來我們將控制器上的Post方法參數(shù)添加[FromBody]標(biāo)識看看，代碼片段變成如下：

[HttpPost]
 public IActionResult Post([FromBody]Customer customer)
 {
  if (!ModelState.IsValid)
  {
  return BadRequest(ModelState);
  }
  return Ok();
 }

這是為何，我們通過[FromBody]特性標(biāo)識后，此時(shí)也將屬性id加上了[BindNever]特性(代碼和如上一樣，不重復(fù)貼了)，結(jié)果id綁定上了，說明[BindNever]特性對通過[FromBody]特性標(biāo)識的參數(shù)無效，情況真的是這樣嗎？接下來我們嘗試將[BindNever]綁定到對象看看，如下：

public class Customer
 {
 public int Id { get; set; }
 }

 [Route("[controller]")]
 public class ModelBindController : Controller
 {
 [HttpPost]
 public IActionResult Post([BindNever][FromBody]Customer customer)
 {
  if (!ModelState.IsValid)
  {
  return BadRequest(ModelState);
  }
  return Ok();
 }
 }

上述我們將[BindNever]綁定到對象Customer上，同時(shí)對于[BindNever]和[FromBody]特性沒有先后順序，也就是說我們也可以將[FromBody]放在[BindNever]后面，接下來我們利用Postman再次發(fā)送如下請求。

此時(shí)我們可以明確看到，我們發(fā)送的請求包含id字段，且此時(shí)我們將[BindNever]綁定到對象上時(shí)，最終id則沒綁定到對象上，達(dá)到我們的預(yù)期且驗(yàn)證通過，但是話說回來，將[BindNever]綁定到對象上毫無意義，因?yàn)榇藭r(shí)對象上所有屬性都將會(huì)被忽略。所以到這里我們可以得出[BindNever]對于[FromBody]特性請求的結(jié)論：

對于使用【FromBody】特性標(biāo)識的請求，【BindNever】特性應(yīng)用到模型上的屬性時(shí)，此時(shí)綁定無效，應(yīng)用到模型對象上時(shí)，此時(shí)將完全忽略對模型對象上的所有屬性

對于來自URL或者表單上的請求，【BindNever】特性應(yīng)用到模型上的屬性時(shí)，此時(shí)綁定無效，應(yīng)用到模型對象時(shí)，此時(shí)將完全忽略對模型對象上的所有屬性

好了，接下來我們再來看看[BindRequired]，我們繼續(xù)給出如下代碼：

public class Customer
 {
 [BindRequired]
 public int Id { get; set; }
 }

 [Route("[controller]")]
 public class ModelBindController : Controller
 {
 [HttpPost]
 public IActionResult Post(Customer customer)
 {
  if (!ModelState.IsValid)
  {
  return BadRequest(ModelState);
  }
  return Ok();
 }
 }

通過[BindRequired]特性標(biāo)識屬性，我們基于表單的請求且未給出屬性id的值，此時(shí)屬性未綁定上且驗(yàn)證未通過，符合我們預(yù)期。接下來我們再來看看【FromBody】特性標(biāo)識的請求，代碼就不給出了，我們只是在對象上加上了[FromBody]而已，我們看看最終結(jié)果。

此時(shí)從表面上看好像達(dá)到了我們的預(yù)期，在這里即使我們對屬性id不指定【BindRequired】特性，結(jié)果也是一樣驗(yàn)證未通過，這是為何，因?yàn)槟J(rèn)情況下，在.NET Core中對于【FromBody】特性標(biāo)識的對象不可為空，內(nèi)置進(jìn)行了處理，我們進(jìn)行如下設(shè)置允許為空。

services.AddMvc(options=> 
  {
  options.AllowEmptyInputInBodyModelBinding = true;
  }).SetCompatibilityVersion(CompatibilityVersion.Version_2_2);

我們進(jìn)行上述設(shè)置后，我們不給定屬性id的值，肯定會(huì)驗(yàn)證通過對不對，那我們接下來再給定一個(gè)屬性Age呢，然后發(fā)出請求不包含Age屬性，如下

public class Customer
 {
 [BindRequired]
 public int Id { get; set; }

 [BindRequired]
 public int Age { get; set; }
 }

到這里我們發(fā)現(xiàn)我們對屬性Age添加了【BindRequired】特性，此時(shí)驗(yàn)證卻是通過的，我們再加思考一番，或許是我們給定的屬性Age是int有默認(rèn)值為0，所以驗(yàn)證通過，好想法，你可以繼續(xù)添加一個(gè)字符串類型的屬性，然后添加【BindRequired】特性，同時(shí)最后請求中不包含該屬性，此時(shí)結(jié)果依然是驗(yàn)證通過的（不信自己試試）。

此時(shí)我們發(fā)現(xiàn)通過[FromBody]特性標(biāo)識的請求，我們將默認(rèn)對象不可空的情況排除在外，說明[BindRequired]特性標(biāo)識的屬性對[FromBody]特性標(biāo)識的請求無效，同時(shí)呢，我們轉(zhuǎn)到[BindRequired]特性的定義有如下解釋：

// 摘要:
// Indicates that a property is required for model binding. When applied to a property, the model binding system requires a value for that property. When applied to
// a type, the model binding system requires values for all properties that type defines.

翻譯過來不難理解，當(dāng)我們通過[BindRequired]特性標(biāo)識時(shí)，說明在模型綁定時(shí)屬性是必須給出的，當(dāng)應(yīng)用到屬性時(shí)，要求模型綁定系統(tǒng)必須驗(yàn)證此屬性的值必須要給出，當(dāng)應(yīng)用到類型時(shí)，要求模型綁定系統(tǒng)必須驗(yàn)證類型中定義的所有屬性必須有值。這個(gè)解釋讓我們無法信服，對于基于URL或者基于表單的請求和【FromBody】特性的請求明顯有區(qū)別，但是定義卻是一概而論。到這里我們遺漏到了一個(gè)【Required】特性，我們添加一個(gè)Address屬性，然后請求中不包含Address屬性，

public class Customer
 {
 [BindRequired]
 public int Id { get; set; }
 [BindRequired]
 public int Age { get; set; }
 [Required]
 public string Address { get; set; }
 }

從上圖看出使用【FromBody】標(biāo)識的請求，通過Required特性標(biāo)識屬性也符合預(yù)期，當(dāng)然對于URL和表單請求也符合預(yù)期，在此不再演示。我并未看過源碼，我大膽猜測下是否是如下原因才有其區(qū)別呢（個(gè)人猜測）

解釋都在強(qiáng)調(diào)模型綁定系統(tǒng)，所以在.NET Core中出現(xiàn)的【BindNever】和【BindRequired】特性專為.NET Core MVC模型綁定系統(tǒng)而設(shè)計(jì)，而對于【FromBody】特性標(biāo)識后，因?yàn)槠溥M(jìn)行屬性的序列化和反序列化與Input Formatter有關(guān)，比如通過JSON.NET，所以至于屬性的忽略和映射與否和我們使用序列化和反序列化的框架有關(guān)，由我們自己來定義，比如使用JSON.NET則屬性忽略使用【JsonIgnore】。

所以說基于【FromBody】特性標(biāo)識的請求，是否映射，是否必須由我們使用的序列化和反序列化框架決定，在.NET Core中默認(rèn)是JSON.NET，所以對于如上屬性是否必須提供，我們需要使用JSON.NET中的Api，比如如下。

public class Customer
 {
 [JsonProperty(Required = Required.Always)]
 public int Id { get; set; }

 [JsonProperty(Required = Required.Always)]
 public int Age { get; set; }
 }

請求參數(shù)安全也是需要我們考慮的因素，比如如下我們對象包含IsAdmin屬性，我們后臺(tái)會(huì)根據(jù)該屬性值判斷是否為對應(yīng)角色進(jìn)行UI的渲染，我們可以通過[Bind]特性應(yīng)用于對象指定映射哪些屬性，此時(shí)請求中參數(shù)即使顯式指定了該參數(shù)值也不會(huì)進(jìn)行映射（這里僅僅只是舉例說明，例子可能并非合理），代碼如下：

public class Customer
 {
 public int Id { get; set; }
 public int Age { get; set; }
 public string Address { get; set; }
 public bool IsAdmin { get; set; }
 }

 [Route("[controller]")]
 public class ModelBindController : Controller
 {
 [HttpPost]
 public IActionResult Post(
  [Bind(nameof(Customer.Id),nameof(Customer.Age),nameof(Customer.Address)
  )] Customer customer)
 {
  if (!ModelState.IsValid)
  {
  return BadRequest(ModelState);
  }
  return Ok();
 }
 }

來源綁定

在.NET Core中出現(xiàn)了不同的特性，比如上述我們所講解的行為綁定，然后是接下來我們要講解的來源綁定，它們出現(xiàn)的意義和作用在哪里呢？它比.NET中的模型綁定更加靈活，而不是一樣，為何靈活不是我嘴上說說而已，通過實(shí)際例子證明給你看，每一個(gè)新功能或特性的出現(xiàn)是為了解決對應(yīng)的問題或改善對應(yīng)的問題，首先我們來看如下代碼：

[Route("[controller]")]
 public class ModelBindController : Controller
 {
 [HttpPost("{id:int}")]
 public IActionResult Post(int id, Customer customer)
 {
  if (!ModelState.IsValid)
  {
  return BadRequest(ModelState);
  }
  return Ok();
 }
 }

我們通過路由指定id為4，然后url上指定為3，你猜映射到后臺(tái)id上的參數(shù)結(jié)果是4還是3呢，在customer上的參數(shù)id是4還是3呢？

從上圖我們看到id是4，而customer對象中的id值為2，我們從中可以得出一個(gè)什么結(jié)論呢，來，我們進(jìn)行如下總結(jié)。

在.NET Core中，默認(rèn)情況下參數(shù)綁定存在優(yōu)先級，路由的優(yōu)先級大于表單的優(yōu)先級，表單的優(yōu)先級大于URL的優(yōu)先級即（路由>表單>URL）

這是默認(rèn)情況下的優(yōu)先級，為什么說在.NET Core中非常靈活呢，因?yàn)槲覀兛梢酝ㄟ^來源進(jìn)行顯式綁定，比如強(qiáng)制指定id來源于查詢字符串，而customer中的id源于查詢路由，如下：

[HttpPost("{id:int}")]
 public IActionResult Post([FromQuery]int id, [FromRoute] Customer customer)
 {
  if (!ModelState.IsValid)
  {
  return BadRequest(ModelState);
  }
  return Ok();
 }

還有什么[FromForm]、[FromServices]、[FromHeader]等來源綁定都是強(qiáng)制指定參數(shù)到底是來源于表單、請求頭、查詢字符串、路由還是Body，到這里無需我再過多講解了，一個(gè)例子足以說明其靈活性。

模型綁定(強(qiáng)大支持舉例)

上述講解來源綁定我們認(rèn)識到其靈活性，可能有部分童鞋壓根都不知道.NET Core中對模型綁定的強(qiáng)大支持，哪里強(qiáng)大了，在講解模型綁定原理之前，來給大家舉幾個(gè)實(shí)際的例子來說明，首先我們來看如下請求代碼：

對于如上請求，我們大部分的做法則是通過如下創(chuàng)建一個(gè)類來接受上述URL參數(shù)。

public class Example
 {
 public int A { get; set; }
 public int B { get; set; }
 public int C { get; set; }
 }

 [Route("[controller]")]
 public class ModelBindController : Controller
 {
 [HttpGet]
 public IActionResult Post(Example employee)
 {
  return Ok();
 }
 }

這種常見做法在ASP.NET MVC/Web Api中也是支持的，好了，接下來我們將上述控制器代碼進(jìn)行如下修改后在.NET Core中是支持的，而在.NET MVC/Web Api中是不支持的，不信，您可以試試。

[Route("[controller]")]
 public class ModelBindController : Controller
 {
 [HttpGet]
 public IActionResult Get(Dictionary<string, int> pairs)
 {
  return Ok();
 }
 }

至于在.NE Core中為何能夠綁定上，主要是在.NET Core實(shí)現(xiàn)了字典的DictionaryModelBinder，所以可以將URL上的參數(shù)當(dāng)做字典的鍵，而參數(shù)值作為鍵對應(yīng)的值，看的不過癮，對不對，好，接下來我們看看如下請求，您覺得控制器應(yīng)該如何接收URL上的參數(shù)呢？

大膽發(fā)揮您的想象，在我們的控制器Action方法上，我們?nèi)绾稳ソ邮丈鲜鯱RL上的參數(shù)呢？好了，不賣關(guān)子了，

[Route("[controller]")]
 public class ModelBindController : Controller
 {
 [HttpGet]
 public IActionResult Post(List<Dictionary<string, int>> pairs)
 {
  return Ok();
 }
 }

是不是說明.NET Core就不支持了呢？顯然不是，我們將參數(shù)名稱需要修改一致才行，我們將URL上的參數(shù)名稱修改為和控制器方法上的參數(shù)一致（當(dāng)然類型也要一致，否則也會(huì)映射不上），如下：

好了，見識到.NET Core中模型綁定系統(tǒng)的強(qiáng)大，接下來我們快馬加鞭去看看模型綁定原理是怎樣的吧，GO。

模型綁定原理

了解模型綁定原理有什么作用呢？當(dāng).NET Core提供給我們的模型綁定系統(tǒng)不滿足我們的需求時(shí)，我們可以自定義模型綁定來實(shí)現(xiàn)我們的需求，這里我簡單說下整個(gè)過程是這樣的，然后呢，給出我畫的一張?jiān)敿?xì)圖關(guān)于模型綁定的整個(gè)過程是這樣。當(dāng)我們在startup中使用services.AddMvc()方法時(shí)，說明我們會(huì)使用MVC框架，此時(shí)在背后對于模型綁定做了什么呢？

【1】初始化ModelBinderProviders集合，并向此集合中添加16個(gè)已經(jīng)實(shí)現(xiàn)的ModelBinderProvider

【2】初始化ValuesProviderFactories集合，并向此集合中添加4個(gè)ValueFactory

【3】以單例形式注入<IModelBinderFactory,ModelBinderFactory>

【4】添加其他模型元數(shù)據(jù)信息

接下來到底是怎樣將參數(shù)進(jìn)行綁定的呢？首先我們來定義一個(gè)IModelBinder接口，如下：

 public interface IModelBinder
 {
 Task BindModelAsync(ModelBindingContext bindingContext);
 }

那這個(gè)接口用來干嘛呢，通過該接口中定義的方法名稱我們就知道，這就是最終我們得到的ModelBinder，繼而通過綁定上下文來綁定參數(shù)， 那么具體ModelBinder又怎么來呢？接下來定義IModelBinderProvder接口，如下：

public interface IModelBinderProvider
 {
 IModelBinder GetBinder(ModelBinderProviderContext context);
 }

通過IModelBinderProvider接口中的ModelBinderProvderContext獲取具體的ModelBinder，那么通過該接口中的方法GetBinder，我們?nèi)绾潍@取具體的ModelBinder呢，換而言之，我們怎么去創(chuàng)建具體的ModelBinder呢，在添加MVC框架時(shí)我們注入了ModelBinderFactory，此時(shí)ModelBinderFactory上場了，代碼如下：

public class ModelBinderFactory : IModelBinderFactory
 {
 public IModelBinder CreateBinder(ModelBinderFactoryContext context)
 {
  .....
 }
 }

那這個(gè)方法內(nèi)部是如何實(shí)現(xiàn)的呢？其實(shí)很簡單，也是在我們添加MVC框架時(shí)，初始了16個(gè)具體ModelBinderProvider即List<IModelBinderProvider>，此時(shí)在這個(gè)方法里面去遍歷這個(gè)集合，此時(shí)上述方法內(nèi)部實(shí)現(xiàn)變成如下偽代碼：

public class ModelBinderFactory : IModelBinderFactory
 {
 public IModelBinder CreateBinder(ModelBinderFactoryContext context)
 {
  IModelBinderProvider[] _providers;
  IModelBinder result = null;

  for (var i = 0; i < _providers.Length; i++)
  {
  var provider = _providers[i];
  result = provider.GetBinder(providerContext);
  if (result != null)
  {
   break;
  }
  }
 }
 }

至于它如何得到是哪一個(gè)具體的ModelBinderProvider的，這就涉及到具體細(xì)節(jié)實(shí)現(xiàn)了，簡單來說根據(jù)綁定來源(Bindingsource)以及對應(yīng)的元數(shù)據(jù)信息而得到，有想看源碼細(xì)節(jié)的童鞋，可將如下圖下載放大后去看。

自定義模型綁定

簡單講了下模型綁定原理，更多細(xì)節(jié)參看上述圖查看，接下來我們動(dòng)手實(shí)踐下，通過上述從整體上的講解，我們知道要想實(shí)現(xiàn)自定義模型綁定，我們必須實(shí)現(xiàn)兩個(gè)接口，實(shí)現(xiàn)IModelBinderProvider接口來實(shí)例化ModelBinder，實(shí)現(xiàn)IModelBinder接口來將參數(shù)進(jìn)行綁定，最后呢，將我們自定義實(shí)現(xiàn)的ModelBinderProvider添加到MVC框架選項(xiàng)中的ModelBinderProvider集合中去。首先我們定義如下類：

public class Employee
 {
 [Required]
 public decimal Salary { get; set; }
 }

我們定義一個(gè)員工類，員工有薪水，如果公司遍布于全世界各地，所以對于各國的幣種不一樣，假設(shè)是中國員工，則幣種為人民幣，假設(shè)一名中國員工薪水為10000人民幣，我們想要將【¥10000】綁定到Salary屬性上，此時(shí)我們通過Postman模擬請求看看。

[Route("[controller]")]
 public class ModelBindController : Controller
 {
 [HttpPost]
 public IActionResult Post(Employee customer)
 {
  if (!ModelState.IsValid)
  {
  return BadRequest(ModelState);
  }
  return Ok();
 }

從如上圖響應(yīng)結(jié)果看出，此時(shí)默認(rèn)的模型綁定系統(tǒng)將不再適用，因?yàn)槲覀兗由狭藥欧N符號，所以此時(shí)我們必須實(shí)現(xiàn)自定義的模型綁定，接下來我們通過兩種不同的方式來實(shí)現(xiàn)自定義模型綁定。

貨幣符號自定義模型綁定方式（一）

我們知道對于貨幣符號可以通過NumberStyles.Currency來指定，有了解過模型綁定原理的童鞋應(yīng)該知道對于在.NET Core默認(rèn)的ModelBinderProviders集合中并有DecimalModelBinderProvider，而是FloatingPointTypeModelBinderProvider來支持貨幣符號，而對應(yīng)背后的具體實(shí)現(xiàn)是DecimalModelBinder，所以我們大可借助于內(nèi)置已經(jīng)實(shí)現(xiàn)的DecimalModelBinder來實(shí)現(xiàn)自定義模型綁定，所以此時(shí)我們僅僅只需要實(shí)現(xiàn)IModelBinderProvider接口，而IModelBinder接口對應(yīng)的就是DecimalModelBinder內(nèi)置已經(jīng)實(shí)現(xiàn)，代碼如下：

public class RMBModelBinderProvider : IModelBinderProvider
 {
 private readonly ILoggerFactory _loggerFactory;
 public RMBModelBinderProvider(ILoggerFactory loggerFactory)
 {
  _loggerFactory = loggerFactory;

 }
 public IModelBinder GetBinder(ModelBinderProviderContext context)
 {
  //元數(shù)據(jù)為復(fù)雜類型直接跳過
  if (context.Metadata.IsComplexType)
  {
  return null;
  }

  //上下文中獲取元數(shù)據(jù)類型非decimal類型直接跳過
  if (context.Metadata.ModelType != typeof(decimal))
  {
  return null;
  }
  
  return new DecimalModelBinder(NumberStyles.Currency, _loggerFactory);
 }
 }

接下來則是將我們上述實(shí)現(xiàn)的RMBModelBinderProvider添加到ModelBinderProviders集合中去，這里需要注意，我們知道最終得到具體的ModelBinder，內(nèi)置是采用遍歷集合而實(shí)現(xiàn)，一旦找到直接跳出，所以我們將自定義實(shí)現(xiàn)的ModelBinderProvider強(qiáng)烈建議添加到集合中首位即使用Insert方法，而不是Add方法，如下：

services.AddMvc(options =>
  {
  var loggerFactory = _serviceProvider.GetService<ILoggerFactory>();
  options.ModelBinderProviders.Insert(0, new RMBModelBinderProvider(loggerFactory));
  }).SetCompatibilityVersion(CompatibilityVersion.Version_2_2);

貨幣符號自定義模型綁定方式（二）

上述我們是采用內(nèi)置提供給我們的DecimalModelBinder解決了貨幣符號問題，接下來我們將通過特性來實(shí)現(xiàn)指定屬性為貨幣符號，首先我們定義如下接口解析屬性值是否成功與否

public interface IRMB
 {
 decimal RMB(string modelValue, out bool success);
 }

然后寫一個(gè)如下RMB屬性特性實(shí)現(xiàn)上述接口。

[AttributeUsage(AttributeTargets.Property)]
 public class RMBAttribute : Attribute, IRMB
 {
 private static NumberStyles styles = NumberStyles.Currency;
 private CultureInfo CultureInfo = new CultureInfo("zh-cn");
 public decimal RMB(string modelValue, out bool success)
 {
  success = decimal.TryParse(modelValue, styles, CultureInfo, out var valueDecimal);
  return valueDecimal;
 }
 }

接下來我們則是實(shí)現(xiàn)IModelBinderProvider接口，然后在此接口實(shí)現(xiàn)中去獲取模型元數(shù)據(jù)類型中的屬性是否實(shí)現(xiàn)了上述RMB特性，如果是，我們則實(shí)例化ModelBinder并將RMB特性傳遞過去并得到其值，完整代碼如下：

public class RMBAttributeModelBinderProvider : IModelBinderProvider
 {
 private readonly ILoggerFactory _loggerFactory;
 public RMBAttributeModelBinderProvider(ILoggerFactory loggerFactory)
 {
  _loggerFactory = loggerFactory;

 }
 public IModelBinder GetBinder(ModelBinderProviderContext context)
 {
  if (!context.Metadata.IsComplexType)
  {
  var propertyName = context.Metadata.PropertyName;
  var propertyInfo = context.Metadata.ContainerMetadata.ModelType.GetProperty(propertyName);
  var attribute = propertyInfo.GetCustomAttributes(typeof(RMBAttribute), false).FirstOrDefault();
  if (attribute != null)
  {
   return new RMBAttributeModelBinder(context.Metadata.ModelType, attribute as RMBAttribute, _loggerFactory);
  }
  }
  return null;
 }
 }

public class RMBAttributeModelBinder : IModelBinder
 {
 IRMB rMB;
 private SimpleTypeModelBinder modelBinder;
 public RMBAttributeModelBinder(Type type, RMBAttribute attribute, ILoggerFactory loggerFactory)
 {
  rMB = attribute as IRMB;
  modelBinder = new SimpleTypeModelBinder(type, loggerFactory);
 }
 public Task BindModelAsync(ModelBindingContext bindingContext)
 {
  var modelName = bindingContext.ModelName;
  var valueProviderResult = bindingContext.ValueProvider.GetValue(modelName);
  if (valueProviderResult != ValueProviderResult.None)
  {
  bindingContext.ModelState.SetModelValue(modelName, valueProviderResult);
  var valueString = valueProviderResult.FirstValue;
  var result = rMB.RMB(valueString, out bool success);
  if (success)
  {
   bindingContext.Result = ModelBindingResult.Success(result);
   return Task.CompletedTask;
  }
  }
  return modelBinder.BindModelAsync(bindingContext);
 }
 }

 services.AddMvc(options =>
 {
  var loggerFactory = _serviceProvider.GetService<ILoggerFactory>();
  options.ModelBinderProviders.Insert(0, new RMBAttributeModelBinderProvider(loggerFactory));
 }).SetCompatibilityVersion(CompatibilityVersion.Version_2_2);

public class Employee
 {
 [Required]
 [RMB]
 public decimal Salary { get; set; }
 }

混合綁定

什么是混合綁定呢？就是將不同的綁定模式混合在一起使用，有的人可說了，你這和沒講有什么區(qū)別，好了，我來舉一個(gè)例子，比如我們想將URL上的參數(shù)綁定到【FromBody】特性的參數(shù)上，前提是在URL上的參數(shù)在【FromBody】參數(shù)沒有，好像還是有點(diǎn)模糊，來，上代碼。

[Route("[controller]")]
 public class ModelBindController : Controller
 {
 [HttpPost("{id:int}")]
 public IActionResult Post([FromBody]Employee customer)
 {
  if (!ModelState.IsValid)
  {
  return BadRequest(ModelState);
  }
  return Ok();
 }
 }

public class Employee
 {
 public int Id { get; set; }
 [Required]
 public decimal Salary { get; set; }
 }

如上示意圖想必已經(jīng)很明確了，在Body中我們并未指定屬性Id，但是我們想要將路由中的id也就是4綁定到【FromBody】標(biāo)識的參數(shù)Employee的屬性Id，例子跟實(shí)際不是合理的，只是為了演示混合綁定，這點(diǎn)請忽略。問題已經(jīng)闡述的非常明確了，不知您是否有了解決思路，既然是【FromBody】，內(nèi)置已經(jīng)實(shí)現(xiàn)的BodyModelBinder我們依然要綁定，我們只需要將路由中的值綁定到Employee對象中的id即可，來，我們首先實(shí)現(xiàn)IModelBinderProvider接口，如下：

public class MixModelBinderProvider : IModelBinderProvider
 {
 private readonly IList<IInputFormatter> _formatters;
 private readonly IHttpRequestStreamReaderFactory _readerFactory;

 public MixModelBinderProvider(IList<IInputFormatter> formatters,
  IHttpRequestStreamReaderFactory readerFactory)
 {
  _formatters = formatters;
  _readerFactory = readerFactory;
 }
 public IModelBinder GetBinder(ModelBinderProviderContext context)
 {
  //如果上下文為空，返回空
  if (context == null)
  {
  throw new ArgumentNullException(nameof(context));
  }

  //如果元數(shù)據(jù)模型類型為Employee實(shí)例化MixModelBinder
  if (context.Metadata.ModelType == typeof(Employee))
  {
  return new MixModelBinder(_formatters, _readerFactory);
  }

  return null;
 }
 }

接下來則是實(shí)現(xiàn)IModelBinder接口諾，綁定【FromBody】特性請求參數(shù)，綁定屬性Id。

public class MixModelBinder : IModelBinder
 {
 private readonly BodyModelBinder bodyModelBinder;
 public MixModelBinder(IList<IInputFormatter> formatters,
  IHttpRequestStreamReaderFactory readerFactory)
 {
  //原來【FromBody】綁定參數(shù)依然要綁定，所以需要實(shí)例化BodyModelBinder
  bodyModelBinder = new BodyModelBinder(formatters, readerFactory);
 }
 public Task BindModelAsync(ModelBindingContext bindingContext)
 {
  if (bindingContext == null)
  {
  throw new ArgumentNullException(nameof(bindingContext));
  }

  //綁定【FromBody】特性請求參數(shù)
  bodyModelBinder.BindModelAsync(bindingContext);

  if (!bindingContext.Result.IsModelSet)
  {
  return null;
  }

  //獲取綁定對象
  var model = bindingContext.Result.Model;

  //綁定屬性Id
  if (model is Employee employee)
  {
  var idString = bindingContext.ValueProvider.GetValue("id").FirstValue;
  if (int.TryParse(idString, out var id))
  {
   employee.Id = id;
  }

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

其實(shí)到這里我們應(yīng)該更加明白，【BindRequired】和【BindNever】特性只針對MVC模型綁定系統(tǒng)起作用，而對于【FromBody】特性的請求參數(shù)與Input Formatter有關(guān)，也就是與所用的序列化和反序列化框架有關(guān)。接下來我們添加自定義實(shí)現(xiàn)的混合綁定類，如下：

services.AddMvc(options =>
  {
  var readerFactory = services.BuildServiceProvider().GetRequiredService<IHttpRequestStreamReaderFactory>();
  options.ModelBinderProviders.Insert(0, new MixModelBinderProvider(options.InputFormatters, readerFactory));
  }).SetCompatibilityVersion(CompatibilityVersion.Version_2_2);

ApiController特性本質(zhì)

.NET Core每個(gè)版本的迭代更新都帶給我們最佳體驗(yàn)，直到.NET Core 2.0版本我們知道MVC和Web Api將控制器合并也就是共同繼承自Controller，但是呢，畢竟如果僅僅只是做Api開發(fā)所以完全用不到MVC中Razor視圖引擎，在.NET Core 2.1版本出現(xiàn)了ApiController特性， 同時(shí)出現(xiàn)了新的約定，也就是我們控制器基類可以不再是Controller而是ControllerBase，這是一個(gè)更加輕量的控制器基類，它不支持Razor視圖引擎，ControllerBase控制器和ApiController特性結(jié)合使用，完全演變成干凈的Api控制器，所以到這里至少我們了解到了.NET Core中的Controller和ControllerBase區(qū)別所在，Controller包含Razor視圖引擎，而要是如果我們僅僅只是做接口開發(fā)，則只需使用ControllerBase控制器結(jié)合ApiController特性即可。那么問題來了，ApiController特性的出現(xiàn)到底為我們帶來了什么呢？說的更加具體一點(diǎn)則是，它為我們解決了什么問題呢？有的人說.NET Core中模型綁定系統(tǒng)或者ApiController特性的出現(xiàn)顯得很復(fù)雜，其實(shí)不然，只是我們不了解背后它所解決的應(yīng)用場景，一旦用了之后，發(fā)現(xiàn)各種問題呈現(xiàn)出來了，還是基礎(chǔ)沒有夯實(shí)，接下來我們一起來看看。在講解模型綁定系統(tǒng)時(shí)，我們了解到對于參數(shù)的驗(yàn)證我們需要通過代碼ModelState.IsValid來判斷，比如如下代碼：

public class Employee
 {
 public int Id { get; set; }

 [Required]
 public string Address { get; set; }
 }

 [Route("[Controller]")]
 public class ModelBindController : Controller
 {
 [HttpPost]
 public IActionResult Post([FromBody]Employee employee)
 {
  if (!ModelState.IsValid)
  {
  return BadRequest(ModelState);
  }
  return Ok();
 }
 }

當(dāng)我們請求參數(shù)中未包含Address屬性時(shí)，此時(shí)通過上述模型驗(yàn)證未通過響應(yīng)400。當(dāng)控制器通過ApiController修飾時(shí)，此時(shí)內(nèi)置會(huì)自動(dòng)進(jìn)行驗(yàn)證，也就是我們不必要在控制器方法中一遍遍寫ModelState.IsValid方法，那么問題來了，內(nèi)置到底是如何進(jìn)行自動(dòng)驗(yàn)證的呢？首先會(huì)在.NET Core應(yīng)用程序初始化時(shí)，注入如下接口以及具體實(shí)現(xiàn)。

services.TryAddEnumerable(
  ServiceDescriptor.Transient<IApplicationModelProvider, ApiBehaviorApplicationModelProvider>());

那么針對ApiBehaviorApplicationModelProvider這個(gè)類到底做了什么呢？在此類構(gòu)造函數(shù)中添加了6個(gè)約定，其他四個(gè)不是我們研究的重點(diǎn)，有興趣的童鞋可以私下去研究，我們看看最重要的兩個(gè)類：InvalidModelStateFilterConvention和InferParameterBindingInfoConvention，然后在此類中有如下方法：

public void OnProvidersExecuting(ApplicationModelProviderContext context)
 {
  foreach (var controller in context.Result.Controllers)
  {
  if (!IsApiController(controller))
  {
   continue;
  }

  foreach (var action in controller.Actions)
  {
   // Ensure ApiController is set up correctly
   EnsureActionIsAttributeRouted(action);

   foreach (var convention in ActionModelConventions)
   {
   convention.Apply(action);
   }
  }
  }
 }

至于方法OnProviderExecuting方法在何時(shí)被調(diào)用我們無需太多關(guān)心，這不是我們研究的重點(diǎn)，我們看到此方法中的具體就是做了判斷我們是否在控制器上通過ApiController進(jìn)行了修飾，如果是，則遍歷我們默認(rèn)添加的6個(gè)約定，好了接下來我們首先來看InvalidModelStateFilterConvention約定，最終我們會(huì)看到此類中添加了ModelStateInvalidFilterFactory，然后針對此類的實(shí)例化ModelStateInvalidFilter類，然后在此類中我們看到實(shí)現(xiàn)了IAactionFilter接口，如下：

public void OnActionExecuting(ActionExecutingContext context)
 {
  if (context.Result == null && !context.ModelState.IsValid)
  {
  _logger.ModelStateInvalidFilterExecuting();
  context.Result = _apiBehaviorOptions.InvalidModelStateResponseFactory(context);
  }
 }

到這里想必我們明白了在控制器上通過ApiController修飾解決了第一個(gè)問題：在添加MVC框架時(shí)，會(huì)為我們注入一個(gè)ModelStateInvalidFilter，并在OnActionExecuting方法期間運(yùn)行，也就是執(zhí)行控制器方法時(shí)運(yùn)行，當(dāng)然也是在進(jìn)行模型綁定之后自動(dòng)進(jìn)行ModelState驗(yàn)證是否有效，未通過則立即響應(yīng)400。到這里是不是就這樣完事了呢，顯然不是，為何，我們在控制器上通過ApiController來進(jìn)行修飾，如下代碼：

[Route("[Controller]")]
 [ApiController]
 public class ModelBindController : Controller
 {
 [HttpPost]
 public IActionResult Post(Employee employee)
 {
  //if (!ModelState.IsValid)
  //{
  // return BadRequest(ModelState);
  //}
  return Ok();
 }
 }

對比上述代碼，我們只是添加ApiController修飾控制器，同時(shí)我們已了然內(nèi)部會(huì)自動(dòng)進(jìn)行模型驗(yàn)證，所以我們注釋了模型驗(yàn)證代碼，然后我們也將【FromBody】特性去除，這時(shí)我們進(jìn)行請求，響應(yīng)如下，符合我們預(yù)期：

我們僅僅只是將添加了ApiController修飾控制器，為何我們將【FromBody】特性去除則請求依然好使，而且結(jié)果也如我們預(yù)期一樣呢？答案則是：參數(shù)來源綁定推斷，通過ApiController修飾控制器，會(huì)用到我們上述提出的第二個(gè)約定類（參數(shù)綁定信息推斷），到了這里是不是發(fā)現(xiàn).NET Core為我們做了好多，別著急，事情還未完全水落石出，接下來我們來看看，我們之前所給出的URL參數(shù)綁定到字典上的例子。

[Route("[Controller]")]
 [ApiController]
 public class ModelBindController : Controller
 {
 [HttpGet]
 public IActionResult Get(List<Dictionary<string, int>> pairs)
 {
  return Ok();
 }
 }

到這里我們瞬間懵逼了，之前的請求現(xiàn)在卻出現(xiàn)了415，也就是媒介類型不支持，我們什么都沒干，只是添加了ApiController修飾控制器而已，如此而已，問題出現(xiàn)了一百八十度的大轉(zhuǎn)折，這個(gè)問題誰來解釋解釋下。我們還是看看參數(shù)綁定信息約定類的具體實(shí)現(xiàn)，一探究竟，如下：

if (!options.SuppressInferBindingSourcesForParameters)
  {
  var convention = new InferParameterBindingInfoConvention(modelMetadataProvider)
  {
   AllowInferringBindingSourceForCollectionTypesAsFromQuery = options.AllowInferringBindingSourceForCollectionTypesAsFromQuery,
  };

  ActionModelConventions.Add(convention);
  }

第一個(gè)判斷則是是否啟動(dòng)參數(shù)來源綁定推斷，告訴我們這是可配置的，好了，我們將其還原不啟用，此時(shí)再請求回歸如初，如下：

services.Configure<ApiBehaviorOptions>(options=>
 {
 options.SuppressInferBindingSourcesForParameters = true;
 }).AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);

那么內(nèi)置到底做了什么，其實(shí)上述答案已經(jīng)給出了，我們看看上述這行代碼：options.AllowInferringBindingSourceForCollectionTypesAsFromQuery，因?yàn)獒槍项愋停?NET Core無從推斷到底是來自于Body還是Query，所以呢，.NET Core再次給定了我們一個(gè)可配置選項(xiàng)，我們顯式配置通過如下配置集合類型是來自于Query，此時(shí)請求則好使，否則將默認(rèn)是Body，所以出現(xiàn)415。

services.Configure<ApiBehaviorOptions>(options=>
{
 options.AllowInferringBindingSourceForCollectionTypesAsFromQuery = true;
}).AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);

好了，上述是針對集合類型進(jìn)行可配置強(qiáng)制指定其來源，那么問題又來了，對于對象又該如何呢？首先我們將上述顯式配置集合類型來源于Query給禁用（禁不禁用皆可），我們看看下如下代碼：

[Route("[Controller]")]
 [ApiController]
 public class ModelBindController : Controller
 {
 [HttpGet("GetEmployee")]
 public IActionResult GetEmployee(Employee employee)
 {
  return Ok();
 }
 }

再次讓我們大跌眼鏡，好像自從添加上了ApiController修飾控制器，各種問題呈現(xiàn)，我們還是看看.NET Core最終其推斷，到底是如何推斷的呢？

internal void InferParameterBindingSources(ActionModel action)
 {
  for (var i = 0; i < action.Parameters.Count; i++)
  {
  var parameter = action.Parameters[i];
  var bindingSource = parameter.BindingInfo?.BindingSource;
  if (bindingSource == null)
  {
   bindingSource = InferBindingSourceForParameter(parameter);

   parameter.BindingInfo = parameter.BindingInfo ?? new BindingInfo();
   parameter.BindingInfo.BindingSource = bindingSource;
  }
  }
  ......
 }

 // Internal for unit testing.
 internal BindingSource InferBindingSourceForParameter(ParameterModel parameter)
 {
  if (IsComplexTypeParameter(parameter))
  {
  return BindingSource.Body;
  }

  if (ParameterExistsInAnyRoute(parameter.Action, parameter.ParameterName))
  {
  return BindingSource.Path;
  }

  return BindingSource.Query;
 }

 private bool ParameterExistsInAnyRoute(ActionModel action, string parameterName)
 {
  foreach (var (route, _, _) in ActionAttributeRouteModel.GetAttributeRoutes(action))
  {
  if (route == null)
  {
   continue;
  }

  var parsedTemplate = TemplateParser.Parse(route.Template);
  if (parsedTemplate.GetParameter(parameterName) != null)
  {
   return true;
  }
  }

  return false;
 }

 private bool IsComplexTypeParameter(ParameterModel parameter)
 {
  // No need for information from attributes on the parameter. Just use its type.
  var metadata = _modelMetadataProvider
  .GetMetadataForType(parameter.ParameterInfo.ParameterType);

  if (AllowInferringBindingSourceForCollectionTypesAsFromQuery && metadata.IsCollectionType)
  {
  return false;
  }

  return metadata.IsComplexType;
 }

通過上述代碼我們可知推斷來源結(jié)果只有三種：Body、Path、Query。因?yàn)槲覀兾达@式配置綁定來源，所以走參數(shù)推斷來源，然后首先判斷是否為復(fù)雜類型，判斷條件是如果AllowInferringBindingSourceForCollectionTypesAsFromQuery配置為true，同時(shí)為集合類型說明來源為Body。此時(shí)我們無論是否顯式配置綁定集合類型是否來源于FromQuery，肯定不滿足這兩個(gè)條件，接著執(zhí)行metadate.IsComplexType，很顯然Employee為復(fù)雜類型，我們再次通過源碼也可證明，在獲取模型元數(shù)據(jù)時(shí)，通過!TypeDescriptor.GetConverter(typeof(ModelType)).CanConvertFrom(typeof(string))判斷是否為復(fù)雜類型，所以此時(shí)返回綁定來源于Body，所以出現(xiàn)415，問題已經(jīng)分析的很清楚了，來，最終，我們給ApiController特性本質(zhì)下一個(gè)結(jié)論：

通過ApiController修飾控制器，內(nèi)置實(shí)現(xiàn)了6個(gè)默認(rèn)約定，其中最重要的兩個(gè)約定則是，其一解決模型自動(dòng)驗(yàn)證，其二則是當(dāng)未配置綁定來源，執(zhí)行參數(shù)推斷來源，但是，但是，這個(gè)僅僅只是針對Body、Path、Query而言。

當(dāng)控制器方法上參數(shù)為字典或集合時(shí)，如果請求參數(shù)來源于URL也就是查詢字符串請顯式配置AllowInferringBindingSourceForCollectionTypesAsFromQuery為true，否則會(huì)推斷綁定來源為Body，從而響應(yīng)415。

當(dāng)控制器方法上參數(shù)為復(fù)雜類型時(shí)，如果請求參數(shù)來源于Body，可以無需顯式配置綁定來源，如果參數(shù)來源為URL也就是查詢字符串，請顯式配置參數(shù)綁定來源【FromQuery】，如果參數(shù)來源于表單，請顯式配置參數(shù)綁定來源【FromForm】，否則會(huì)推斷綁定為Body，從而響應(yīng)415。

總結(jié)

本文比較詳細(xì)的闡述了.NET Core中的模型綁定系統(tǒng)、模型綁定原理、自定義模型綁定原理、混合綁定等等，其實(shí)還有一些基礎(chǔ)內(nèi)容我還未寫出，后續(xù)有可能我接著研究并補(bǔ)上，.NET Core中強(qiáng)大的模型綁定支持以及靈活性控制都是.NET MVC/Web Api不可比擬的，雖然很基礎(chǔ)但是又有多少人知道并且了解過這些呢，同時(shí)針對ApiController特性確實(shí)給我們省去了不必要的代碼，但是帶來的參數(shù)來源推斷讓我們有點(diǎn)懵逼，如果不看源碼，斷不可知這些，我個(gè)人認(rèn)為針對添加ApiController特性后的參數(shù)來源推斷，沒什么鳥用，強(qiáng)烈建議顯式配置綁定來源，也就不必記住上述結(jié)論了，本篇文章耗費(fèi)我三天時(shí)間所寫，修修補(bǔ)補(bǔ)，其中所帶來的價(jià)值，一個(gè)字：值。

最新評論