前言
好久沒冒泡了，算起來估計有快半年沒更新博客了，估計是我第一次停更如此之久，人總有懶惰的時候，時間越長越懶惰，但是呢，不學又不行，持續的惰性是不行dei，要不然會被時光所拋棄，技術所淘汰，好吧，進入今天的主題，本節內容，我們來講講.NET Core當中的模型綁定系統、模型綁定原理、自定義模型綁定、混合綁定、ApiController特性本質，可能有些園友已經看過，但是效果不太好哈，這篇是解釋最為詳細的一篇，建議已經學過我發布課程的童鞋也看下，本篇內容略長，請保持耐心，我只講你們會用到的或者說能夠學到東西的內容。
模型綁定系統
對于模型綁定，.NET Core給我們提供了[BindRequired]、[BindNever]、[FromHeader]、[FromQuery]、[FromRoute]、[FromForm]、[FromServices]、[FromBody]等特性，[BindRequired]和[BindNever]翻譯成必須綁定，從不綁定我們稱之為行為綁定，而緊跟后面的五個From，翻譯成從哪里來，我們稱之為來源綁定，下面我們詳細介紹這兩種綁定類型，本節內容使用版本.NET Core 2.2版本。
行為綁定
[BindRequired]表示參數的鍵必須要提供，但是并不關心參數的值是否為空，[BindNever]表示忽略對屬性的綁定，行為綁定看似很簡單，其實不然，待我娓娓道來，首先我們來看如下代碼片段。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
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(); } } |
上述我們定義了一個Customer類，然后類中的id字段通過[BindNever]特性進行標識，接下來我們一切都通過Postman來發出請求
當我們如上發送請求時，響應將返回狀態碼200成功且id沒有綁定上，符合我們的預期，其意思就是從不綁定屬性id，好接下來我們將控制器上的Post方法參數添加[FromBody]標識看看，代碼片段變成如下：
|
1
2
3
4
5
6
7
8
9
|
[HttpPost] public IActionResult Post([FromBody]Customer customer) { if (!ModelState.IsValid) { return BadRequest(ModelState); } return Ok(); } |
這是為何，我們通過[FromBody]特性標識后，此時也將屬性id加上了[BindNever]特性(代碼和如上一樣，不重復貼了)，結果id綁定上了，說明[BindNever]特性對通過[FromBody]特性標識的參數無效，情況真的是這樣嗎？接下來我們嘗試將[BindNever]綁定到對象看看，如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
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上，同時對于[BindNever]和[FromBody]特性沒有先后順序，也就是說我們也可以將[FromBody]放在[BindNever]后面，接下來我們利用Postman再次發送如下請求。
此時我們可以明確看到，我們發送的請求包含id字段，且此時我們將[BindNever]綁定到對象上時，最終id則沒綁定到對象上，達到我們的預期且驗證通過，但是話說回來，將[BindNever]綁定到對象上毫無意義，因為此時對象上所有屬性都將會被忽略。所以到這里我們可以得出[BindNever]對于[FromBody]特性請求的結論：
對于使用【FromBody】特性標識的請求，【BindNever】特性應用到模型上的屬性時，此時綁定無效，應用到模型對象上時，此時將完全忽略對模型對象上的所有屬性
對于來自URL或者表單上的請求，【BindNever】特性應用到模型上的屬性時，此時綁定無效，應用到模型對象時，此時將完全忽略對模型對象上的所有屬性
好了，接下來我們再來看看[BindRequired]，我們繼續給出如下代碼：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
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]特性標識屬性，我們基于表單的請求且未給出屬性id的值，此時屬性未綁定上且驗證未通過，符合我們預期。接下來我們再來看看【FromBody】特性標識的請求，代碼就不給出了，我們只是在對象上加上了[FromBody]而已，我們看看最終結果。
此時從表面上看好像達到了我們的預期，在這里即使我們對屬性id不指定【BindRequired】特性，結果也是一樣驗證未通過，這是為何，因為默認情況下，在.NET Core中對于【FromBody】特性標識的對象不可為空，內置進行了處理，我們進行如下設置允許為空。
|
1
2
3
4
|
services.AddMvc(options=> { options.AllowEmptyInputInBodyModelBinding = true; }).SetCompatibilityVersion(CompatibilityVersion.Version_2_2); |
我們進行上述設置后，我們不給定屬性id的值，肯定會驗證通過對不對，那我們接下來再給定一個屬性Age呢，然后發出請求不包含Age屬性，如下
|
1
2
3
4
5
6
7
8
|
public class Customer { [BindRequired] public int Id { get; set; } [BindRequired] public int Age { get; set; } } |
到這里我們發現我們對屬性Age添加了【BindRequired】特性，此時驗證卻是通過的，我們再加思考一番，或許是我們給定的屬性Age是int有默認值為0，所以驗證通過，好想法，你可以繼續添加一個字符串類型的屬性，然后添加【BindRequired】特性，同時最后請求中不包含該屬性，此時結果依然是驗證通過的（不信自己試試）。
此時我們發現通過[FromBody]特性標識的請求，我們將默認對象不可空的情況排除在外，說明[BindRequired]特性標識的屬性對[FromBody]特性標識的請求無效，同時呢，我們轉到[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.
翻譯過來不難理解，當我們通過[BindRequired]特性標識時，說明在模型綁定時屬性是必須給出的，當應用到屬性時，要求模型綁定系統必須驗證此屬性的值必須要給出，當應用到類型時，要求模型綁定系統必須驗證類型中定義的所有屬性必須有值。這個解釋讓我們無法信服，對于基于URL或者基于表單的請求和【FromBody】特性的請求明顯有區別，但是定義卻是一概而論。到這里我們遺漏到了一個【Required】特性，我們添加一個Address屬性，然后請求中不包含Address屬性，
|
1
2
3
4
5
6
7
8
9
|
public class Customer { [BindRequired] public int Id { get; set; } [BindRequired] public int Age { get; set; } [Required] public string Address { get; set; } } |
從上圖看出使用【FromBody】標識的請求，通過Required特性標識屬性也符合預期，當然對于URL和表單請求也符合預期，在此不再演示。我并未看過源碼，我大膽猜測下是否是如下原因才有其區別呢（個人猜測）
解釋都在強調模型綁定系統，所以在.NET Core中出現的【BindNever】和【BindRequired】特性專為.NET Core MVC模型綁定系統而設計，而對于【FromBody】特性標識后，因為其進行屬性的序列化和反序列化與Input Formatter有關，比如通過JSON.NET，所以至于屬性的忽略和映射與否和我們使用序列化和反序列化的框架有關，由我們自己來定義，比如使用JSON.NET則屬性忽略使用【JsonIgnore】。
所以說基于【FromBody】特性標識的請求，是否映射，是否必須由我們使用的序列化和反序列化框架決定，在.NET Core中默認是JSON.NET，所以對于如上屬性是否必須提供，我們需要使用JSON.NET中的Api，比如如下。
|
1
2
3
4
5
6
7
8
|
public class Customer { [JsonProperty(Required = Required.Always)] public int Id { get; set; } [JsonProperty(Required = Required.Always)] public int Age { get; set; } } |
請求參數安全也是需要我們考慮的因素，比如如下我們對象包含IsAdmin屬性，我們后臺會根據該屬性值判斷是否為對應角色進行UI的渲染，我們可以通過[Bind]特性應用于對象指定映射哪些屬性，此時請求中參數即使顯式指定了該參數值也不會進行映射（這里僅僅只是舉例說明，例子可能并非合理），代碼如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
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中出現了不同的特性，比如上述我們所講解的行為綁定，然后是接下來我們要講解的來源綁定，它們出現的意義和作用在哪里呢？它比.NET中的模型綁定更加靈活，而不是一樣，為何靈活不是我嘴上說說而已，通過實際例子證明給你看，每一個新功能或特性的出現是為了解決對應的問題或改善對應的問題，首先我們來看如下代碼：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
[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，你猜映射到后臺id上的參數結果是4還是3呢，在customer上的參數id是4還是3呢？
從上圖我們看到id是4，而customer對象中的id值為2，我們從中可以得出一個什么結論呢，來，我們進行如下總結。
在.NET Core中，默認情況下參數綁定存在優先級，路由的優先級大于表單的優先級，表單的優先級大于URL的優先級即（路由>表單>URL）
這是默認情況下的優先級，為什么說在.NET Core中非常靈活呢，因為我們可以通過來源進行顯式綁定，比如強制指定id來源于查詢字符串，而customer中的id源于查詢路由，如下：
|
1
2
3
4
5
6
7
8
9
|
[HttpPost("{id:int}")] public IActionResult Post([FromQuery]int id, [FromRoute] Customer customer) { if (!ModelState.IsValid) { return BadRequest(ModelState); } return Ok(); } |
還有什么[FromForm]、[FromServices]、[FromHeader]等來源綁定都是強制指定參數到底是來源于表單、請求頭、查詢字符串、路由還是Body，到這里無需我再過多講解了，一個例子足以說明其靈活性。
模型綁定(強大支持舉例)
上述講解來源綁定我們認識到其靈活性，可能有部分童鞋壓根都不知道.NET Core中對模型綁定的強大支持，哪里強大了，在講解模型綁定原理之前，來給大家舉幾個實際的例子來說明，首先我們來看如下請求代碼：
對于如上請求，我們大部分的做法則是通過如下創建一個類來接受上述URL參數。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
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中也是支持的，好了，接下來我們將上述控制器代碼進行如下修改后在.NET Core中是支持的，而在.NET MVC/Web Api中是不支持的，不信，您可以試試。
|
1
2
3
4
5
6
7
8
9
|
[Route("[controller]")] public class ModelBindController : Controller { [HttpGet] public IActionResult Get(Dictionary<string, int> pairs) { return Ok(); } } |
至于在.NE Core中為何能夠綁定上，主要是在.NET Core實現了字典的DictionaryModelBinder，所以可以將URL上的參數當做字典的鍵，而參數值作為鍵對應的值，看的不過癮，對不對，好，接下來我們看看如下請求，您覺得控制器應該如何接收URL上的參數呢？
大膽發揮您的想象，在我們的控制器Action方法上，我們如何去接收上述URL上的參數呢？好了，不賣關子了，
|
1
2
3
4
5
6
7
8
9
|
[Route("[controller]")] public class ModelBindController : Controller { [HttpGet] public IActionResult Post(List<Dictionary<string, int>> pairs) { return Ok(); } } |
是不是說明.NET Core就不支持了呢？顯然不是，我們將參數名稱需要修改一致才行，我們將URL上的參數名稱修改為和控制器方法上的參數一致（當然類型也要一致，否則也會映射不上），如下：
好了，見識到.NET Core中模型綁定系統的強大，接下來我們快馬加鞭去看看模型綁定原理是怎樣的吧，GO。
模型綁定原理
了解模型綁定原理有什么作用呢？當.NET Core提供給我們的模型綁定系統不滿足我們的需求時，我們可以自定義模型綁定來實現我們的需求，這里我簡單說下整個過程是這樣的，然后呢，給出我畫的一張詳細圖關于模型綁定的整個過程是這樣。當我們在startup中使用services.AddMvc()方法時，說明我們會使用MVC框架，此時在背后對于模型綁定做了什么呢？
【1】初始化ModelBinderProviders集合，并向此集合中添加16個已經實現的ModelBinderProvider
【2】初始化ValuesProviderFactories集合，并向此集合中添加4個ValueFactory
【3】以單例形式注入<IModelBinderFactory,ModelBinderFactory>
【4】添加其他模型元數據信息
接下來到底是怎樣將參數進行綁定的呢？首先我們來定義一個IModelBinder接口，如下：
|
1
2
3
4
|
public interface IModelBinder{Task BindModelAsync(ModelBindingContext bindingContext);} |
那這個接口用來干嘛呢，通過該接口中定義的方法名稱我們就知道，這就是最終我們得到的ModelBinder，繼而通過綁定上下文來綁定參數， 那么具體ModelBinder又怎么來呢？接下來定義IModelBinderProvder接口，如下：
|
1
2
3
4
|
public interface IModelBinderProvider { IModelBinder GetBinder(ModelBinderProviderContext context); } |
通過IModelBinderProvider接口中的ModelBinderProvderContext獲取具體的ModelBinder，那么通過該接口中的方法GetBinder，我們如何獲取具體的ModelBinder呢，換而言之，我們怎么去創建具體的ModelBinder呢，在添加MVC框架時我們注入了ModelBinderFactory，此時ModelBinderFactory上場了，代碼如下：
|
1
2
3
4
5
6
7
|
public class ModelBinderFactory : IModelBinderFactory { public IModelBinder CreateBinder(ModelBinderFactoryContext context) { ..... } } |
那這個方法內部是如何實現的呢？其實很簡單，也是在我們添加MVC框架時，初始了16個具體ModelBinderProvider即List<IModelBinderProvider>，此時在這個方法里面去遍歷這個集合，此時上述方法內部實現變成如下偽代碼：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
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; } } } } |
至于它如何得到是哪一個具體的ModelBinderProvider的，這就涉及到具體細節實現了，簡單來說根據綁定來源(Bindingsource)以及對應的元數據信息而得到，有想看源碼細節的童鞋，可將如下圖下載放大后去看。
自定義模型綁定
簡單講了下模型綁定原理，更多細節參看上述圖查看，接下來我們動手實踐下，通過上述從整體上的講解，我們知道要想實現自定義模型綁定，我們必須實現兩個接口，實現IModelBinderProvider接口來實例化ModelBinder，實現IModelBinder接口來將參數進行綁定，最后呢，將我們自定義實現的ModelBinderProvider添加到MVC框架選項中的ModelBinderProvider集合中去。首先我們定義如下類：
|
1
2
3
4
5
|
public class Employee { [Required] public decimal Salary { get; set; } } |
我們定義一個員工類，員工有薪水，如果公司遍布于全世界各地，所以對于各國的幣種不一樣，假設是中國員工，則幣種為人民幣，假設一名中國員工薪水為10000人民幣，我們想要將【¥10000】綁定到Salary屬性上，此時我們通過Postman模擬請求看看。
|
1
2
3
4
5
6
7
8
9
10
11
12
|
[Route("[controller]")] public class ModelBindController : Controller { [HttpPost] public IActionResult Post(Employee customer) { if (!ModelState.IsValid) { return BadRequest(ModelState); } return Ok(); } |
從如上圖響應結果看出，此時默認的模型綁定系統將不再適用，因為我們加上了幣種符號，所以此時我們必須實現自定義的模型綁定，接下來我們通過兩種不同的方式來實現自定義模型綁定。
貨幣符號自定義模型綁定方式（一）
我們知道對于貨幣符號可以通過NumberStyles.Currency來指定，有了解過模型綁定原理的童鞋應該知道對于在.NET Core默認的ModelBinderProviders集合中并有DecimalModelBinderProvider，而是FloatingPointTypeModelBinderProvider來支持貨幣符號，而對應背后的具體實現是DecimalModelBinder，所以我們大可借助于內置已經實現的DecimalModelBinder來實現自定義模型綁定，所以此時我們僅僅只需要實現IModelBinderProvider接口，而IModelBinder接口對應的就是DecimalModelBinder內置已經實現，代碼如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
public class RMBModelBinderProvider : IModelBinderProvider { private readonly ILoggerFactory _loggerFactory; public RMBModelBinderProvider(ILoggerFactory loggerFactory) { _loggerFactory = loggerFactory; } public IModelBinder GetBinder(ModelBinderProviderContext context) { //元數據為復雜類型直接跳過 if (context.Metadata.IsComplexType) { return null; } //上下文中獲取元數據類型非decimal類型直接跳過 if (context.Metadata.ModelType != typeof(decimal)) { return null; } return new DecimalModelBinder(NumberStyles.Currency, _loggerFactory); } } |
接下來則是將我們上述實現的RMBModelBinderProvider添加到ModelBinderProviders集合中去，這里需要注意，我們知道最終得到具體的ModelBinder，內置是采用遍歷集合而實現，一旦找到直接跳出，所以我們將自定義實現的ModelBinderProvider強烈建議添加到集合中首位即使用Insert方法，而不是Add方法，如下：
|
1
2
3
4
5
|
services.AddMvc(options => { var loggerFactory = _serviceProvider.GetService<ILoggerFactory>(); options.ModelBinderProviders.Insert(0, new RMBModelBinderProvider(loggerFactory)); }).SetCompatibilityVersion(CompatibilityVersion.Version_2_2); |
貨幣符號自定義模型綁定方式（二）
上述我們是采用內置提供給我們的DecimalModelBinder解決了貨幣符號問題，接下來我們將通過特性來實現指定屬性為貨幣符號，首先我們定義如下接口解析屬性值是否成功與否
|
1
2
3
4
|
public interface IRMB { decimal RMB(string modelValue, out bool success); } |
然后寫一個如下RMB屬性特性實現上述接口。
|
1
2
3
4
5
6
7
8
9
10
11
|
[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; } } |
接下來我們則是實現IModelBinderProvider接口，然后在此接口實現中去獲取模型元數據類型中的屬性是否實現了上述RMB特性，如果是，我們則實例化ModelBinder并將RMB特性傳遞過去并得到其值，完整代碼如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
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; } } |
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
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); } } |
|
1
2
3
4
5
|
services.AddMvc(options =>{ var loggerFactory = _serviceProvider.GetService<ILoggerFactory>(); options.ModelBinderProviders.Insert(0, new RMBAttributeModelBinderProvider(loggerFactory));}).SetCompatibilityVersion(CompatibilityVersion.Version_2_2); |
|
1
2
3
4
5
6
|
public class Employee { [Required] [RMB] public decimal Salary { get; set; } } |
混合綁定
什么是混合綁定呢？就是將不同的綁定模式混合在一起使用，有的人可說了，你這和沒講有什么區別，好了，我來舉一個例子，比如我們想將URL上的參數綁定到【FromBody】特性的參數上，前提是在URL上的參數在【FromBody】參數沒有，好像還是有點模糊，來，上代碼。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
[Route("[controller]")] public class ModelBindController : Controller { [HttpPost("{id:int}")] public IActionResult Post([FromBody]Employee customer) { if (!ModelState.IsValid) { return BadRequest(ModelState); } return Ok(); } } |
|
1
2
3
4
5
6
|
public class Employee { public int Id { get; set; } [Required] public decimal Salary { get; set; } } |
如上示意圖想必已經很明確了，在Body中我們并未指定屬性Id，但是我們想要將路由中的id也就是4綁定到【FromBody】標識的參數Employee的屬性Id，例子跟實際不是合理的，只是為了演示混合綁定，這點請忽略。問題已經闡述的非常明確了，不知您是否有了解決思路，既然是【FromBody】，內置已經實現的BodyModelBinder我們依然要綁定，我們只需要將路由中的值綁定到Employee對象中的id即可，來，我們首先實現IModelBinderProvider接口，如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
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)); } //如果元數據模型類型為Employee實例化MixModelBinder if (context.Metadata.ModelType == typeof(Employee)) { return new MixModelBinder(_formatters, _readerFactory); } return null; } } |
接下來則是實現IModelBinder接口諾，綁定【FromBody】特性請求參數，綁定屬性Id。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
|
public class MixModelBinder : IModelBinder { private readonly BodyModelBinder bodyModelBinder; public MixModelBinder(IList<IInputFormatter> formatters, IHttpRequestStreamReaderFactory readerFactory) { //原來【FromBody】綁定參數依然要綁定，所以需要實例化BodyModelBinder bodyModelBinder = new BodyModelBinder(formatters, readerFactory); } public Task BindModelAsync(ModelBindingContext bindingContext) { if (bindingContext == null) { throw new ArgumentNullException(nameof(bindingContext)); } //綁定【FromBody】特性請求參數 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; } } |
其實到這里我們應該更加明白，【BindRequired】和【BindNever】特性只針對MVC模型綁定系統起作用，而對于【FromBody】特性的請求參數與Input Formatter有關，也就是與所用的序列化和反序列化框架有關。接下來我們添加自定義實現的混合綁定類，如下：
|
1
2
3
4
5
|
services.AddMvc(options => { var readerFactory = services.BuildServiceProvider().GetRequiredService<IHttpRequestStreamReaderFactory>(); options.ModelBinderProviders.Insert(0, new MixModelBinderProvider(options.InputFormatters, readerFactory)); }).SetCompatibilityVersion(CompatibilityVersion.Version_2_2); |
ApiController特性本質
.NET Core每個版本的迭代更新都帶給我們最佳體驗，直到.NET Core 2.0版本我們知道MVC和Web Api將控制器合并也就是共同繼承自Controller，但是呢，畢竟如果僅僅只是做Api開發所以完全用不到MVC中Razor視圖引擎，在.NET Core 2.1版本出現了ApiController特性， 同時出現了新的約定，也就是我們控制器基類可以不再是Controller而是ControllerBase，這是一個更加輕量的控制器基類，它不支持Razor視圖引擎，ControllerBase控制器和ApiController特性結合使用，完全演變成干凈的Api控制器，所以到這里至少我們了解到了.NET Core中的Controller和ControllerBase區別所在，Controller包含Razor視圖引擎，而要是如果我們僅僅只是做接口開發，則只需使用ControllerBase控制器結合ApiController特性即可。那么問題來了，ApiController特性的出現到底為我們帶來了什么呢？說的更加具體一點則是，它為我們解決了什么問題呢？有的人說.NET Core中模型綁定系統或者ApiController特性的出現顯得很復雜，其實不然，只是我們不了解背后它所解決的應用場景，一旦用了之后，發現各種問題呈現出來了，還是基礎沒有夯實，接下來我們一起來看看。在講解模型綁定系統時，我們了解到對于參數的驗證我們需要通過代碼ModelState.IsValid來判斷，比如如下代碼：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
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(); } } |
當我們請求參數中未包含Address屬性時，此時通過上述模型驗證未通過響應400。當控制器通過ApiController修飾時，此時內置會自動進行驗證，也就是我們不必要在控制器方法中一遍遍寫ModelState.IsValid方法，那么問題來了，內置到底是如何進行自動驗證的呢？首先會在.NET Core應用程序初始化時，注入如下接口以及具體實現。
|
1
2
|
services.TryAddEnumerable( ServiceDescriptor.Transient<IApplicationModelProvider, ApiBehaviorApplicationModelProvider>()); |
那么針對ApiBehaviorApplicationModelProvider這個類到底做了什么呢？在此類構造函數中添加了6個約定，其他四個不是我們研究的重點，有興趣的童鞋可以私下去研究，我們看看最重要的兩個類：InvalidModelStateFilterConvention和InferParameterBindingInfoConvention，然后在此類中有如下方法：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
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方法在何時被調用我們無需太多關心，這不是我們研究的重點，我們看到此方法中的具體就是做了判斷我們是否在控制器上通過ApiController進行了修飾，如果是，則遍歷我們默認添加的6個約定，好了接下來我們首先來看InvalidModelStateFilterConvention約定，最終我們會看到此類中添加了ModelStateInvalidFilterFactory，然后針對此類的實例化ModelStateInvalidFilter類，然后在此類中我們看到實現了IAactionFilter接口，如下：
|
1
2
3
4
5
6
7
8
|
public void OnActionExecuting(ActionExecutingContext context) { if (context.Result == null && !context.ModelState.IsValid) { _logger.ModelStateInvalidFilterExecuting(); context.Result = _apiBehaviorOptions.InvalidModelStateResponseFactory(context); } } |
到這里想必我們明白了在控制器上通過ApiController修飾解決了第一個問題：在添加MVC框架時，會為我們注入一個ModelStateInvalidFilter，并在OnActionExecuting方法期間運行，也就是執行控制器方法時運行，當然也是在進行模型綁定之后自動進行ModelState驗證是否有效，未通過則立即響應400。到這里是不是就這樣完事了呢，顯然不是，為何，我們在控制器上通過ApiController來進行修飾，如下代碼：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
[Route("[Controller]")] [ApiController] public class ModelBindController : Controller { [HttpPost] public IActionResult Post(Employee employee) { //if (!ModelState.IsValid) //{ // return BadRequest(ModelState); //} return Ok(); } } |
對比上述代碼，我們只是添加ApiController修飾控制器，同時我們已了然內部會自動進行模型驗證，所以我們注釋了模型驗證代碼，然后我們也將【FromBody】特性去除，這時我們進行請求，響應如下，符合我們預期：
我們僅僅只是將添加了ApiController修飾控制器，為何我們將【FromBody】特性去除則請求依然好使，而且結果也如我們預期一樣呢？答案則是：參數來源綁定推斷，通過ApiController修飾控制器，會用到我們上述提出的第二個約定類（參數綁定信息推斷），到了這里是不是發現.NET Core為我們做了好多，別著急，事情還未完全水落石出，接下來我們來看看，我們之前所給出的URL參數綁定到字典上的例子。
|
1
2
3
4
5
6
7
8
9
10
|
[Route("[Controller]")] [ApiController] public class ModelBindController : Controller { [HttpGet] public IActionResult Get(List<Dictionary<string, int>> pairs) { return Ok(); } } |
到這里我們瞬間懵逼了，之前的請求現在卻出現了415，也就是媒介類型不支持，我們什么都沒干，只是添加了ApiController修飾控制器而已，如此而已，問題出現了一百八十度的大轉折，這個問題誰來解釋解釋下。我們還是看看參數綁定信息約定類的具體實現，一探究竟，如下：
|
1
2
3
4
5
6
7
8
9
|
if (!options.SuppressInferBindingSourcesForParameters) { var convention = new InferParameterBindingInfoConvention(modelMetadataProvider) { AllowInferringBindingSourceForCollectionTypesAsFromQuery = options.AllowInferringBindingSourceForCollectionTypesAsFromQuery, }; ActionModelConventions.Add(convention); } |
第一個判斷則是是否啟動參數來源綁定推斷，告訴我們這是可配置的，好了，我們將其還原不啟用，此時再請求回歸如初，如下：
|
1
2
3
4
|
services.Configure<ApiBehaviorOptions>(options=> { options.SuppressInferBindingSourcesForParameters = true; }).AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2); |
那么內置到底做了什么，其實上述答案已經給出了，我們看看上述這行代碼：options.AllowInferringBindingSourceForCollectionTypesAsFromQuery，因為針對集合類型，.NET Core無從推斷到底是來自于Body還是Query，所以呢，.NET Core再次給定了我們一個可配置選項，我們顯式配置通過如下配置集合類型是來自于Query，此時請求則好使，否則將默認是Body，所以出現415。
|
1
2
3
4
|
services.Configure<ApiBehaviorOptions>(options=>{ options.AllowInferringBindingSourceForCollectionTypesAsFromQuery = true;}).AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2); |
好了，上述是針對集合類型進行可配置強制指定其來源，那么問題又來了，對于對象又該如何呢？首先我們將上述顯式配置集合類型來源于Query給禁用（禁不禁用皆可），我們看看下如下代碼：
|
1
2
3
4
5
6
7
8
9
10
|
[Route("[Controller]")] [ApiController] public class ModelBindController : Controller { [HttpGet("GetEmployee")] public IActionResult GetEmployee(Employee employee) { return Ok(); } } |
再次讓我們大跌眼鏡，好像自從添加上了ApiController修飾控制器，各種問題呈現，我們還是看看.NET Core最終其推斷，到底是如何推斷的呢？
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
|
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; } |
通過上述代碼我們可知推斷來源結果只有三種：Body、Path、Query。因為我們未顯式配置綁定來源，所以走參數推斷來源，然后首先判斷是否為復雜類型，判斷條件是如果AllowInferringBindingSourceForCollectionTypesAsFromQuery配置為true，同時為集合類型說明來源為Body。此時我們無論是否顯式配置綁定集合類型是否來源于FromQuery，肯定不滿足這兩個條件，接著執行metadate.IsComplexType，很顯然Employee為復雜類型，我們再次通過源碼也可證明，在獲取模型元數據時，通過!TypeDescriptor.GetConverter(typeof(ModelType)).CanConvertFrom(typeof(string))判斷是否為復雜類型，所以此時返回綁定來源于Body，所以出現415，問題已經分析的很清楚了，來，最終，我們給ApiController特性本質下一個結論：
通過ApiController修飾控制器，內置實現了6個默認約定，其中最重要的兩個約定則是，其一解決模型自動驗證，其二則是當未配置綁定來源，執行參數推斷來源，但是，但是，這個僅僅只是針對Body、Path、Query而言。
當控制器方法上參數為字典或集合時，如果請求參數來源于URL也就是查詢字符串請顯式配置AllowInferringBindingSourceForCollectionTypesAsFromQuery為true，否則會推斷綁定來源為Body，從而響應415。
當控制器方法上參數為復雜類型時，如果請求參數來源于Body，可以無需顯式配置綁定來源，如果參數來源為URL也就是查詢字符串，請顯式配置參數綁定來源【FromQuery】，如果參數來源于表單，請顯式配置參數綁定來源【FromForm】，否則會推斷綁定為Body，從而響應415。
總結
本文比較詳細的闡述了.NET Core中的模型綁定系統、模型綁定原理、自定義模型綁定原理、混合綁定等等，其實還有一些基礎內容我還未寫出，后續有可能我接著研究并補上，.NET Core中強大的模型綁定支持以及靈活性控制都是.NET MVC/Web Api不可比擬的，雖然很基礎但是又有多少人知道并且了解過這些呢，同時針對ApiController特性確實給我們省去了不必要的代碼，但是帶來的參數來源推斷讓我們有點懵逼，如果不看源碼，斷不可知這些，我個人認為針對添加ApiController特性后的參數來源推斷，沒什么鳥用，強烈建議顯式配置綁定來源，也就不必記住上述結論了，本篇文章耗費我三天時間所寫，修修補補，其中所帶來的價值，一個字：值。
原文鏈接：https://www.cnblogs.com/CreateMyself/p/10604293.html
