知識星球冒個泡，算起來估計有很長時間沒更新公眾號了，估計是我第一次停更如此之久，人總有懶惰的時候，時間越長越懶惰，但是呢，不學又不行，持續的惰性是不行dei，要不然會被時光所拋棄，技術所淘汰，好吧，進入今天的主題，本節內容，我們來講講.NET Core當中的模型系結系統、模型系結原理、自定義模型系結、混合系結、ApiController特性本質，可能有些童鞋已經看過，但是效果不太好哈，這篇是解釋最為詳細的一篇，建議已經學過我釋出課程的童鞋也看下，本篇內容略長，請保持耐心，我只講你們會用到的或者說能夠學到東西的內容。
模型系結系統
對於模型系結，.NET Core給我們提供了[BindRequired]、[BindNever]、[FromHeader]、[FromQuery]、[FromRoute]、[FromForm]、[FromServices]、[FromBody]等特性，[BindRequired]和[BindNever]翻譯成必須系結，從不繫結我們稱之為行為系結，而緊跟後面的五個From，翻譯成從哪裡來，我們稱之為來源系結，下麵我們詳細介紹這兩種系結型別，本節內容使用版本.NET Core 2.2版本。
行為系結
[BindRequired]表示引數的鍵必須要提供，但是並不關心引數的值是否為空，[BindNever]表示忽略對屬性的系結，行為系結看似很簡單，其實不然，待我娓娓道來，首先我們來看如下程式碼片段。
上述我們定義了一個Customer類，然後類中的id欄位透過[BindNever]特性進行標識，接下來我們一切都透過Postman來發出請求
當我們如上傳送請求時，響應將傳回狀態碼200成功且id沒有系結上，符合我們的預期，其意思就是從不繫結屬性id，好接下來我們將控制器上的Post方法引數新增[FromBody]標識看看，程式碼片段變成如下：
這是為何，我們透過[FromBody]特性標識後，此時也將屬性id加上了[BindNever]特性(程式碼和如上一樣，不重覆貼了)，結果id系結上了，說明[BindNever]特性對透過[FromBody]特性標識的引數無效，情況真的是這樣嗎？接下來我們嘗試將[BindNever]系結到物件看看，如下：
上述我們將[BindNever]系結到物件Customer上，同時對於[BindNever]和[FromBody]特性沒有先後順序，也就是說我們也可以將[FromBody]放在[BindNever]後面，接下來我們利用Postman再次傳送如下請求。
此時我們可以明確看到，我們傳送的請求包含id欄位，且此時我們將[BindNever]系結到物件上時，最終id則沒系結到物件上，達到我們的預期且驗證透過，但是話說回來，將[BindNever]系結到物件上毫無意義，因為此時物件上所有屬性都將會被忽略。所以到這裡我們可以得出[BindNever]對於[FromBody]特性請求的結論：
【1】對於使用【FromBody】特性標識的請求，【BindNever】特性應用到模型上的屬性時，此時系結無效，應用到模型物件上時，此時將完全忽略對模型物件上的所有屬性
【2】對於來自URL或者表單上的請求，【BindNever】特性應用到模型上的屬性時，此時系結無效，應用到模型物件時，此時將完全忽略對模型物件上的所有屬性
好了，接下來我們再來看看[BindRequired]，我們繼續給出如下程式碼：
透過[BindRequired]特性標識屬性，我們基於表單的請求且未給出屬性id的值，此時屬性未系結上且驗證未透過，符合我們預期。接下來我們再來看看【FromBody】特性標識的請求，程式碼就不給出了，我們只是在物件上加上了[FromBody]而已，我們看看最終結果。
此時從錶面上看好像達到了我們的預期，在這裡即使我們對屬性id不指定【BindRequired】特性，結果也是一樣驗證未透過，這是為何，因為預設情況下，在.NET Core中對於【FromBody】特性標識的物件不可為空，內建進行了處理，我們進行如下設定允許為空。
我們進行上述設定後，我們不給定屬性id的值，肯定會驗證透過對不對，那我們接下來再給定一個屬性Age呢，然後發出請求不包含Age屬性，如下
到這裡我們發現我們對屬性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屬性，
從上圖看出使用【FromBody】標識的請求，透過Required特性標識屬性也符合預期，當然對於URL和表單請求也符合預期，在此不再演示。我並未看過原始碼，我大膽猜測下是否是如下原因才有其區別呢（個人猜測）
【1】解釋都在強調模型系結系統，所以在.NET Core中出現的【BindNever】和【BindRequired】特性專為.NET Core MVC模型系結系統而設計。
【2】而對於【FromBody】特性標識後，因為其進行屬性的序列化和反序列化與Input Formatter有關，比如透過JSON.NET，所以至於屬性的忽略和對映與否和我們使用序列化和反序列化的框架有關，由我們自己來定義，比如使用JSON.NET則屬性忽略使用【JsonIgnore】。
所以說基於【FromBody】特性標識的請求，是否對映，是否必須由我們使用的序列化和反序列化框架決定，在.NET Core中預設是JSON.NET，所以對於如上屬性是否必須提供，我們需要使用JSON.NET中的Api，比如如下。
請求引數安全也是需要我們考慮的因素，比如如下我們物件包含IsAdmin屬性，我們後臺會根據該屬性值判斷是否為對應角色進行UI的渲染，我們可以透過[Bind]特性應用於物件指定對映哪些屬性，此時請求中引數即使顯式指定了該引數值也不會進行對映（這裡僅僅只是舉例說明，例子可能並非合理），程式碼如下：
來源系結
在.NET Core中出現了不同的特性，比如上述我們所講解的行為系結，然後是接下來我們要講解的來源系結，它們出現的意義和作用在哪裡呢？它比.NET中的模型系結更加靈活，而不是一樣，為何靈活不是我嘴上說說而已，透過實際例子證明給你看，每一個新功能或特性的出現是為瞭解決對應的問題或改善對應的問題，首先我們來看如下程式碼：
我們透過路由指定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源於查詢路由，如下：
還有什麼[FromForm]、[FromServices]、[FromHeader]等來源系結都是強制指定引數到底是來源於表單、請求頭、查詢字串、路由還是Body，到這裡無需我再過多講解了，一個例子足以說明其靈活性。
模型系結(強大支援舉例)
上述講解來源系結我們認識到其靈活性，可能有部分童鞋壓根都不知道.NET Core中對模型系結的強大支援，哪裡強大了，在講解模型系結原理之前，來給大家舉幾個實際的例子來說明，首先我們來看如下請求程式碼：
對於如上請求，我們大部分的做法則是透過如下建立一個類來接受上述URL引數。
這種常見做法在ASP.NET MVC/Web Api中也是支援的，好了，接下來我們將上述控制器程式碼進行如下修改後在.NET Core中是支援的，而在.NET MVC/Web Api中是不支援的，不信，您可以試試。
至於在.NE Core中為何能夠系結上，主要是在.NET Core實現了字典的DictionaryModelBinder，所以可以將URL上的引數當做字典的鍵，而引數值作為鍵對應的值，看的不過癮，對不對，好，接下來我們看看如下請求，您覺得控制器應該如何接收URL上的引數呢？
大膽發揮您的想象，在我們的控制器Action方法上，我們如何去接收上述URL上的引數呢？好了，不賣關子了，
是不是說明.NET Core就不支援了呢？顯然不是，我們將引數名稱需要修改一致才行，我們將URL上的引數名稱修改為和控制器方法上的引數一致（當然型別也要一致，否則也會對映不上），如下：
好了，見識到.NET Core中模型系結系統的強大，接下來我們快馬加鞭去看看模型系結原理是怎樣的吧，GO。
模型系結原理
瞭解模型系結原理有什麼作用呢？當.NET Core提供給我們的模型系結系統不滿足我們的需求時，我們可以自定義模型系結來實現我們的需求，這裡我簡單說下整個過程是這樣的，然後呢，給出我畫的一張詳細圖關於模型系結的整個過程是這樣。當我們在startup中使用services.AddMvc()方法時，說明我們會使用MVC框架，此時在背後對於模型系結做了什麼呢？
【1】初始化ModelBinderProviders集合，並向此集合中新增16個已經實現的ModelBinderProvider
【2】初始化ValuesProviderFactories集合，並向此集合中新增4個ValueFactory
【3】以單例形式註入
【4】新增其他模型元資料資訊
接下來到底是怎樣將引數進行系結的呢？首先我們來定義一個IModelBinder介面，如下：
那這個介面用來幹嘛呢，透過該介面中定義的方法名稱我們就知道，這就是最終我們得到的ModelBinder，繼而透過系結背景關係來系結引數， 那麼具體ModelBinder又怎麼來呢？接下來定義IModelBinderProvder介面，如下：
透過IModelBinderProvider介面中的ModelBinderProvderContext獲取具體的ModelBinder，那麼透過該介面中的方法GetBinder，我們如何獲取具體的ModelBinder呢，換而言之，我們怎麼去建立具體的ModelBinder呢，在新增MVC框架時我們註入了ModelBinderFactory，此時ModelBinderFactory上場了，程式碼如下：
那這個方法內部是如何實現的呢？其實很簡單，也是在我們新增MVC框架時，初始了16個具體ModelBinderProvider即List，此時在這個方法裡面去遍歷這個集合，此時上述方法內部實現變成如下偽程式碼：
至於它如何得到是哪一個具體的ModelBinderProvider的，這就涉及到具體細節實現了，簡單來說根據系結來源(Bindingsource)以及對應的元資料資訊而得到，有想看原始碼細節的童鞋，可將如下圖下載放大後去看。
自定義模型系結
簡單講了下模型系結原理，更多細節參看上述圖檢視，接下來我們動手實踐下，透過上述從整體上的講解，我們知道要想實現自定義模型系結，我們必須實現兩個介面，實現IModelBinderProvider介面來實體化ModelBinder，實現IModelBinder介面來將引數進行系結，最後呢，將我們自定義實現的ModelBinderProvider新增到MVC框架選項中的ModelBinderProvider集合中去。首先我們定義如下類：
我們定義一個員工類，員工有薪水，如果公司遍佈於全世界各地，所以對於各國的幣種不一樣，假設是中國員工，則幣種為人民幣，假設一名中國員工薪水為10000人民幣，我們想要將【¥10000】系結到Salary屬性上，此時我們透過Postman模擬請求看看。
從如上圖響應結果看出，此時預設的模型系結系統將不再適用，因為我們加上了幣種符號，所以此時我們必須實現自定義的模型系結，接下來我們透過兩種不同的方式來實現自定義模型系結。
貨幣符號自定義模型系結方式（一）
我們知道對於貨幣符號可以透過NumberStyles.Currency來指定，有瞭解過模型系結原理的童鞋應該知道對於在.NET Core預設的ModelBinderProviders集合中並有DecimalModelBinderProvider，而是FloatingPointTypeModelBinderProvider來支援貨幣符號，而對應背後的具體實現是DecimalModelBinder。
所以我們大可藉助於內建已經實現的DecimalModelBinder來實現自定義模型系結，所以此時我們僅僅只需要實現IModelBinderProvider介面，而IModelBinder介面對應的就是DecimalModelBinder內建已經實現，程式碼如下：
接下來則是將我們上述實現的RMBModelBinderProvider新增到ModelBinderProviders集合中去，這裡需要註意，我們知道最終得到具體的ModelBinder，內建是採用遍歷集合而實現，一旦找到直接跳出，所以我們將自定義實現的ModelBinderProvider強烈建議新增到集合中首位即使用Insert方法，而不是Add方法，如下：
貨幣符號自定義模型系結方式（二）
上述我們是採用內建提供給我們的DecimalModelBinder解決了貨幣符號問題，接下來我們將透過特性來實現指定屬性為貨幣符號，首先我們定義如下介面解析屬性值是否成功與否
然後寫一個如下RMB屬性特性實現上述介面。
接下來我們則是實現IModelBinderProvider介面，然後在此介面實現中去獲取模型元資料型別中的屬性是否實現了上述RMB特性，如果是，我們則實體化ModelBinder並將RMB特性傳遞過去並得到其值，完整程式碼如下：
最後則是新增到集合中去併在屬性Salary上使用RMB特性，比如ModelBinderContext和ModelBinderProviderContext背景關係是什麼，無非就是模型元資料和一些引數罷了，這裡就不一一解釋了，自己除錯還會瞭解的更多。如下：
混合系結
什麼是混合系結呢？就是將不同的系結樣式混合在一起使用，有的人可說了，你這和沒講有什麼區別，好了，我來舉一個例子，比如我們想將URL上的引數系結到【FromBody】特性的引數上，前提是在URL上的引數在【FromBody】引數沒有，好像還是有點模糊，來，上程式碼。
如上示意圖想必已經很明確了，在Body中我們並未指定屬性Id，但是我們想要將路由中的id也就是4系結到【FromBody】標識的引數Employee的屬性Id，例子跟實際不是合理的，只是為了演示混合系結，這點請忽略。問題已經闡述的非常明確了，不知您是否有瞭解決思路，既然是【FromBody】，內建已經實現的BodyModelBinder我們依然要系結，我們只需要將路由中的值系結到Employee物件中的id即可，來，我們首先實現IModelBinderProvider介面，如下：
接下來則是實現IModelBinder介面諾，系結【FromBody】特性請求引數，系結屬性Id。
其實到這裡我們應該更加明白，【BindRequired】和【BindNever】特性只針對MVC模型系結系統起作用，而對於【FromBody】特性的請求引數與Input Formatter有關，也就是與所用的序列化和反序列化框架有關。接下來我們新增自定義實現的混合系結類，如下：
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 來判斷，比如如下程式碼：
當我們請求引數中未包含Address屬性時，此時透過上述模型驗證未透過響應400。當控制器透過ApiController修飾時，此時內建會自動進行驗證，也就是我們不必要在控制器方法中一遍遍寫ModelState.IsValid方法，那麼問題來了，內建到底是如何進行自動驗證的呢？首先會在.NET Core應用程式初始化時，註入如下介面以及具體實現。
那麼針對ApiBehaviorApplicationModelProvider這個類到底做了什麼呢？在此類建構式中添加了6個約定，其他四個不是我們研究的重點，有興趣的童鞋可以私下去研究，我們看看最重要的兩個類： InvalidModelStateFilterConvention 和 InferParameterBindingInfoConvention ，然後在此類中有如下方法：
至於方法OnProviderExecuting方法在何時被呼叫我們無需太多關心，這不是我們研究的重點，我們看到此方法中的具體就是做了判斷我們是否在控制器上透過ApiController進行了修飾，如果是，則遍歷我們預設新增的6個約定，好了接下來我們首先來看InvalidModelStateFilterConvention約定，最終我們會看到此類中添加了ModelStateInvalidFilterFactory，然後針對此類的實體化ModelStateInvalidFilter類，然後在此類中我們看到實現了IAactionFilter介面，如下：
到這裡想必我們明白了在控制器上透過ApiController修飾解決了第一個問題：在新增MVC框架時，會我們註入一個ModelStateInvalidFilter，併在OnActionExecuting方法期間執行，也就是執行控制器方法時執行，當然也是在進行模型系結之後自動進行ModelState驗證是否有效，未透過則立即響應400。到這裡是不是就這樣完事了呢，顯然不是，為何，我們在控制器上透過ApiController來進行修飾，如下程式碼：
對比上述程式碼，我們只是新增ApiController修飾控制器，同時我們已瞭然內部會自動進行模型驗證，所以我們註釋了模型驗證程式碼，然後我們也將【FromBody】特性去除，這時我們進行請求，響應如下，符合我們預期：
我們僅僅只是將添加了ApiController修飾控制器，為何我們將【FromBody】特性去除則請求依然好使，而且結果也如我們預期一樣呢？答案則是：引數來源系結推斷，透過ApiController修飾控制器，會用到我們上述提出的第二個約定類（引數系結資訊推斷），到了這裡是不是發現.NET Core為我們做了好多，彆著急，事情還未完全水落石出，接下來我們來看看，我們之前所給出的URL引數系結到字典上的例子。
到這裡我們瞬間懵逼了，之間的請求現在卻出現了415，也就是媒介型別不支援，我們什麼都沒乾，只是添加了ApiController修飾控制器而已，如此而已，問題出現了一百八十度的大轉折，這個問題誰來解釋解釋下。我們還是看看引數系結資訊約定類的具體實現，一探究竟，如下：
第一個判斷則是是否啟動引數來源系結推斷，告訴我們這是可配置的，好了，我們將其還原不啟用，此時再請求回歸如初，如下：
那麼內建到底做了什麼，其實上述答案已經給出了，我們看看上述這行程式碼： options.AllowInferringBindingSourceForCollectionTypesAsFromQuery ，因為針對集合型別，.NET Core無從推斷到底是來自於Body還是Query，所以呢，.NET Core再次給定了我們一個可配置選項，我們顯式配置透過如下配置集合型別是來自於Query，此時請求則好使，否則將預設是Body，所以出現415。
好了，上述是針對集合型別進行可配置強制指定其來源，那麼問題又來了，對於物件又該如何呢？首先我們將上述顯式配置集合型別來源於Query給禁用（禁不禁用皆可），我們看看下如下程式碼：
再次讓我們大跌眼鏡，好像自從新增上了ApiController修飾控制器，各種問題呈現，我們還是看看.NET Core最終其推斷，到底是如何推斷的呢？
透過上述程式碼我們可知推斷來源結果只有三種：Body、Path、Query。因為我們未顯式配置系結來源，所以走引數推斷來源，然後首先判斷是否為複雜型別，判斷條件是如果AllowInferringBindingSourceForCollectionTypesAsFromQuery配置為true，同時為集合型別說明來源為Body。此時我們無論是否顯式配置系結集合型別是否來源於FromQuery，肯定不滿足這兩個條件，接著執行metadate.IsComplexType，很顯然Employee為複雜型別，我們再次透過原始碼也可證明，在獲取模型元資料時，透過 !TypeDescriptor.GetConverter(typeof(ModelType)).CanConvertFrom(typeof(string)) 判斷是否為複雜型別，所以此時傳回系結來源於Body，所以出現415，問題已經分析的很清楚了，來，最終，我們給ApiController特性本質下一個結論：
【1】透過ApiController修飾控制器，內建實現了6個預設約定，其中最重要的兩個約定則是，其一解決模型自動驗證，其二則是當未配置系結來源，執行引數推斷來源，但是，但是，這個僅僅只是針對Body、Path、Query而言。
【2】當控制器方法上引數為字典或集合時，如果請求引數來源於URL也就是查詢字串請顯式配置AllowInferringBindingSourceForCollectionTypesAsFromQuery為true，否則會推斷系結來源為Body，從而響應415。
【3】當控制器方法上引數為物件時，如果請求引數來源於Body，可以無需顯式配置系結來源，如果引數來源為URL也就是查詢字串，請顯式配置引數系結來源【FromQuery】，如果引數來源於表單，請顯式配置引數系結來源【FromForm】，否則會推斷系結為Body，從而響應415。
本文比較詳細的闡述了.NET Core中的模型系結系統、模型系結原理、自定義模型系結原理、混合系結等等，其實還有一些基礎內容我還未寫出，後續有可能我接著研究並補上，.NET Core中強大的模型系結支援以及靈活性控制都是.NET MVC/Web Api不可比擬的，雖然很基礎但是又有多少人知道並且瞭解過這些呢，同時針對ApiController特性確實給我們省去了不必要的程式碼，但是帶來的引數來源推斷讓我們有點懵逼，如果不看原始碼，斷不可知這些，我個人認為針對新增ApiController特性後的引數來源推斷，沒什麼鳥用，強烈建議顯式配置系結來源，也就不必記住上述結論了，本篇文章耗費我三天時間所寫，修修補補，其中所帶來的價值，一個字：值。
