>前言

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

模型綁定系統(tǒng)

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

行為綁定

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

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類(lèi)，然后類(lèi)中的id字段通過(guò)[BindNever]特性進(jìn)行標(biāo)識(shí)，接下來(lái)我們一切都通過(guò)Postman來(lái)發(fā)出請(qǐng)求

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

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

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

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]綁定到對(duì)象Customer上，同時(shí)對(duì)于[BindNever]和[FromBody]特性沒(méi)有先后順序，也就是說(shuō)我們也可以將[FromBody]放在[BindNever]后面，接下來(lái)我們利用Postman再次發(fā)送如下請(qǐng)求。

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

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

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

好了，接下來(lái)我們?cè)賮?lái)看看[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();
 }
 }

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

此時(shí)從表面上看好像達(dá)到了我們的預(yù)期，在這里即使我們對(duì)屬性id不指定【BindRequired】特性，結(jié)果也是一樣驗(yàn)證未通過(guò)，這是為何，因?yàn)槟J(rèn)情況下，在.NET Core中對(duì)于【FromBody】特性標(biāo)識(shí)的對(duì)象不可為空，內(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)證通過(guò)對(duì)不對(duì)，那我們接下來(lái)再給定一個(gè)屬性Age呢，然后發(fā)出請(qǐng)求不包含Age屬性，如下

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

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

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

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

// 摘要:
// 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.

翻譯過(guò)來(lái)不難理解，當(dāng)我們通過(guò)[BindRequired]特性標(biāo)識(shí)時(shí)，說(shuō)明在模型綁定時(shí)屬性是必須給出的，當(dāng)應(yīng)用到屬性時(shí)，要求模型綁定系統(tǒng)必須驗(yàn)證此屬性的值必須要給出，當(dāng)應(yīng)用到類(lèi)型時(shí)，要求模型綁定系統(tǒng)必須驗(yàn)證類(lèi)型中定義的所有屬性必須有值。這個(gè)解釋讓我們無(wú)法信服，對(duì)于基于URL或者基于表單的請(qǐng)求和【FromBody】特性的請(qǐng)求明顯有區(qū)別，但是定義卻是一概而論。到這里我們遺漏到了一個(gè)【Required】特性，我們添加一個(gè)Address屬性，然后請(qǐng)求中不包含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)識(shí)的請(qǐng)求，通過(guò)Required特性標(biāo)識(shí)屬性也符合預(yù)期，當(dāng)然對(duì)于URL和表單請(qǐng)求也符合預(yù)期，在此不再演示。我并未看過(guò)源碼，我大膽猜測(cè)下是否是如下原因才有其區(qū)別呢（個(gè)人猜測(cè)）

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

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

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

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

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

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();
 }
 }

來(lái)源綁定

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

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

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

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

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

這是默認(rèn)情況下的優(yōu)先級(jí)，為什么說(shuō)在.NET Core中非常靈活呢，因?yàn)槲覀兛梢酝ㄟ^(guò)來(lái)源進(jìn)行顯式綁定，比如強(qiáng)制指定id來(lái)源于查詢字符串，而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]等來(lái)源綁定都是強(qiáng)制指定參數(shù)到底是來(lái)源于表單、請(qǐng)求頭、查詢字符串、路由還是Body，到這里無(wú)需我再過(guò)多講解了，一個(gè)例子足以說(shuō)明其靈活性。

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

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

對(duì)于如上請(qǐng)求，我們大部分的做法則是通過(guò)如下創(chuàng)建一個(gè)類(lèi)來(lái)接受上述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();
 }
 }

這種常見(jiàn)做法在ASP.NET MVC/Web Api中也是支持的，好了，接下來(lái)我們將上述控制器代碼進(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ù)值作為鍵對(duì)應(yīng)的值，看的不過(guò)癮，對(duì)不對(duì)，好，接下來(lái)我們看看如下請(qǐng)求，您覺(jué)得控制器應(yīng)該如何接收URL上的參數(shù)呢？

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

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

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

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

模型綁定原理

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

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

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

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

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

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

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

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

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

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

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

那這個(gè)方法內(nèi)部是如何實(shí)現(xiàn)的呢？其實(shí)很簡(jiǎn)單，也是在我們添加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)了，簡(jiǎn)單來(lái)說(shuō)根據(jù)綁定來(lái)源(Bindingsource)以及對(duì)應(yīng)的元數(shù)據(jù)信息而得到，有想看源碼細(xì)節(jié)的童鞋，可將如下圖下載放大后去看。

自定義模型綁定

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

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

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

[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符號(hào)，所以此時(shí)我們必須實(shí)現(xiàn)自定義的模型綁定，接下來(lái)我們通過(guò)兩種不同的方式來(lái)實(shí)現(xiàn)自定義模型綁定。

貨幣符號(hào)自定義模型綁定方式（一）

我們知道對(duì)于貨幣符號(hào)可以通過(guò)NumberStyles.Currency來(lái)指定，有了解過(guò)模型綁定原理的童鞋應(yīng)該知道對(duì)于在.NET Core默認(rèn)的ModelBinderProviders集合中并有DecimalModelBinderProvider，而是FloatingPointTypeModelBinderProvider來(lái)支持貨幣符號(hào)，而對(duì)應(yīng)背后的具體實(shí)現(xiàn)是DecimalModelBinder，所以我們大可借助于內(nèi)置已經(jīng)實(shí)現(xiàn)的DecimalModelBinder來(lái)實(shí)現(xiàn)自定義模型綁定，所以此時(shí)我們僅僅只需要實(shí)現(xiàn)IModelBinderProvider接口，而IModelBinder接口對(duì)應(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ù)雜類(lèi)型直接跳過(guò)
  if (context.Metadata.IsComplexType)
  {
  return null;
  }

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

接下來(lái)則是將我們上述實(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);

貨幣符號(hào)自定義模型綁定方式（二）

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

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

然后寫(xiě)一個(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;
 }
 }

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

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; }
 }

混合綁定

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

[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í)的參數(shù)Employee的屬性Id，例子跟實(shí)際不是合理的，只是為了演示混合綁定，這點(diǎn)請(qǐng)忽略。問(wèn)題已經(jīng)闡述的非常明確了，不知您是否有了解決思路，既然是【FromBody】，內(nèi)置已經(jīng)實(shí)現(xiàn)的BodyModelBinder我們依然要綁定，我們只需要將路由中的值綁定到Employee對(duì)象中的id即可，來(lái)，我們首先實(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ù)模型類(lèi)型為Employee實(shí)例化MixModelBinder
  if (context.Metadata.ModelType == typeof(Employee))
  {
  return new MixModelBinder(_formatters, _readerFactory);
  }

  return null;
 }
 }

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

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

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

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

  //獲取綁定對(duì)象
  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】特性只針對(duì)MVC模型綁定系統(tǒng)起作用，而對(duì)于【FromBody】特性的請(qǐng)求參數(shù)與Input Formatter有關(guān)，也就是與所用的序列化和反序列化框架有關(guān)。接下來(lái)我們添加自定義實(shí)現(xiàn)的混合綁定類(lèi)，如下：

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

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

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

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

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

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

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

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

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

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

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

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

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

  ActionModelConventions.Add(convention);
  }

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

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

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

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

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

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

再次讓我們大跌眼鏡，好像自從添加上了ApiController修飾控制器，各種問(wèn)題呈現(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;
 }

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

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

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

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

總結(jié)

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

最新評(píng)論