你所不知道的ASP.NET Core MVC/WebApi基礎系列 (二)

来源:https://www.cnblogs.com/cxt618/archive/2019/04/06/10661592.html
-Advertisement-
Play Games

轉自博客：https://www.cnblogs.com/CreateMyself/p/10604293.html 前言 本節內容，我們來講講.NET Core當中的模型綁定系統、模型綁定原理、自定義模型綁定、混合綁定、ApiController特性本質，可能有些園友已經看過，但是效果不太好哈，這篇 ...


轉自博客：https://www.cnblogs.com/CreateMyself/p/10604293.html

前言

本節內容，我們來講講.NET Core當中的模型綁定系統、模型綁定原理、自定義模型綁定、混合綁定、ApiController特性本質，可能有些園友已經看過，但是效果不太好哈，這篇是解釋最為詳細的一篇，建議已經學過我發佈課程的童鞋也看下，本篇內容略長，請保持耐心，我只講你們會用到的或者說能夠學到東西的內容。 

模型綁定系統

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

行為綁定

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

    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]標識看看，代碼片段變成如下： 

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

　　這是為何，我們通過[FromBody]特性標識後，此時也將屬性id加上了[BindNever]特性(代碼和如上一樣，不重覆貼了)，結果id綁定上了，說明[BindNever]特性對通過[FromBody]特性標識的參數無效，情況真的是這樣嗎？接下來我們嘗試將[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上，同時對於[BindNever]和[FromBody]特性沒有先後順序，也就是說我們也可以將[FromBody]放在[BindNever]後面，接下來我們利用Postman再次發送如下請求。

 

　　此時我們可以明確看到，我們發送的請求包含id欄位，且此時我們將[BindNever]綁定到對象上時，最終id則沒綁定到對象上，達到我們的預期且驗證通過，但是話說回來，將[BindNever]綁定到對象上毫無意義，因為此時對象上所有屬性都將會被忽略。所以到這裡我們可以得出[BindNever]對於[FromBody]特性請求的結論：

 

對於使用【FromBody】特性標識的請求，【BindNever】特性應用到模型上的屬性時，此時綁定無效，應用到模型對象上時，此時將完全忽略對模型對象上的所有屬性

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

 

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

    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】特性標識的對象不可為空，內置進行了處理，我們進行如下設置允許為空。 

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

　　到這裡我們發現我們對屬性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屬性 

    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，比如如下：

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

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

　　請求參數安全也是需要我們考慮的因素，比如如下我們對象包含IsAdmin屬性，我們後臺會根據該屬性值判斷是否為對應角色進行UI的渲染，我們可以通過[Bind]特性應用於對象指定映射哪些屬性，此時請求中參數即使顯式指定了該參數值也不會進行映射（這裡僅僅只是舉例說明，例子可能並非合理），代碼如下：

    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中的模型綁定更加靈活，而不是一樣，為何靈活不是我嘴上說說而已，通過實際例子證明給你看，每一個新功能或特性的出現是為瞭解決對應的問題或改善對應的問題，首先我們來看如下代碼： 

    [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上指定為2，你猜映射到後臺id上的參數結果是4還是2呢，在customer上的參數id是4還是2呢？

　　從上圖我們看到id是4，而customer對象中的id值為2，我們從中可以得出一個什麼結論呢，來，我們進行如下總結。

　　在.NET Core中，預設情況下參數綁定存在優先順序，路由的優先順序大於表單的優先順序，表單的優先順序大於URL的優先順序即（路由>表單>URL）

　　這是預設情況下的優先順序，為什麼說在.NET Core中非常靈活呢，因為我們可以通過來源進行顯式綁定，比如強制指定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]等來源綁定都是強制指定參數到底是來源於表單、請求頭、查詢字元串、路由還是Body，到這裡無需我再過多講解了，一個例子足以說明其靈活性。

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

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

　　對於如上請求，我們大部分的做法則是通過如下創建一個類來接受上述URL參數。 

    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中是不支持的，不信，您可以試試。 

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

　　至於在.NET Core中為何能夠綁定上，主要是在.NET Core實現了字典的DictionaryModelBinder，所以可以將URL上的參數當做字典的鍵，而參數值作為鍵對應的值，看的不過癮，對不對，好，接下來我們看看如下請求，您覺得控制器應該如何接收URL上的參數呢？

 

　　大膽發揮您的想象，在我們的控制器Action方法上，我們如何去接收上述URL上的參數呢？好了，不賣關子了 

    [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介面，如下：

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

　　那這個介面用來幹嘛呢，通過該介面中定義的方法名稱我們就知道，這就是最終我們得到的ModelBinder，繼而通過綁定上下文來綁定參數， 那麼具體ModelBinder又怎麼來呢？接下來定義IModelBinderProvder介面，如下：

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

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

    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集合中去。首先我們定義如下類： 

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

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

    [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內置已經實現，代碼如下： 

    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方法，如下: 

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

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

 上述我們是採用內置提供給我們的DecimalModelBinder解決了貨幣符號問題，接下來我們將通過特性來實現指定屬性為貨幣符號，首先我們定義如下介面解析屬性值是否成功與否

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

然後寫一個如下RMB屬性特性實現上述介面。

    [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特性傳遞過去並得到其值，完整代碼如下：

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

　　最後則是添加到集合中去併在屬性Salary上使用RMB特性，比如ModelBinderContext和ModelBinderProviderContext上下文是什麼，無非就是模型元數據和一些參數罷了，這裡就不一一解釋了，自己調試還會瞭解的更多。如下：

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

混合綁定 

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

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

　　如上示意圖想必已經很明確了，在Body中我們並未指定屬性Id，但是我們想要將路由中的id也就是4綁定到【FromBody】標識的參數Employee的屬性Id，例子跟實際不是合理的，只是為了演示混合綁定，這點請忽略。問題已經闡述的非常明確了，不知您是否有瞭解決思路，既然是【FromBody】，內置已經實現的BodyModelBinder我們依然要綁定，我們只需要將路由中的值綁定到Employee對象中的id即可，來，我們首先實現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));
            }

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

            return null;
        }
    }

接下來則是實現IModelBinder介面諾，綁定【FromBody】特性請求參數，綁定屬性Id。 

    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有關，也就是與所用的序列化和反序列化框架有關。接下來我們添加自定義實現的混合綁定類，如下：

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 來判斷，比如如下代碼： 

    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應用程式初始化時，註入如下介面以及具體實現。 

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

　　那麼針對ApiBehaviorApplicationModelProvider這個類到底做了什麼呢？在此類構造函數中添加了6個約定，其他四個不是我們研究的重點，有興趣的童鞋可以私下去研究，我們看看最重要的兩個類： 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方法在何時被調用我們無需太多關心，這不是我們研究的重點，我們看到此方法中的具體就是做了判斷我們是否在控制器上通過ApiController進行了修飾，如果是，則遍歷我們預設添加的6個約定，好了接下來我們首先來看InvalidModelStateFilterConvention約定，最終我們會看到此類中添加了ModelStateInvalidFilterFactory，然後針對此類的實例化ModelStateInvalidFilter類，然後在此類中我們看到實現了IAactionFilter介面，如下： 

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來進行修飾，如下代碼：

    [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修飾控制器，會用到我們上述提出的第二個約定類（參數綁定信息推斷），到了這裡是

您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 【2】學習C++之引用
    C++中的引用類似於現實生活中人們之間起昵稱，昵稱和本名都可以辨別人。 1.普通變數的引用： 其中不能光有昵稱沒有本名，如果只定義了引用，卻沒有將這個引用指向哪個變數，編譯器會報錯。 2.結構體的引用： 3.指針類型的引用： 一般形式為——類型 *&指針引用名 = 指針； 4.引用作為函數參數： 兩 ...
  • python數據分析系列(1)
    這個系列主要參考Wes McKinney的Python for Data Analysis,也是對自己在平時學習工作中遇到的一些問題還有小技巧的總結。 ...
  • 類模版與函數模版
    ``` // // main.cpp // 類模版與函數模版 // 在類聲明中使用類型參數來聲明通用的類 // Created by mac on 2019/4/6. // Copyright © 2019年 mac. All rights reserved. // 一個類模版中是否支持多種類型的參 ...
  • NLPIR（北理工張華平版中文分詞系統）的SDK(C++)調用方法
    一、本文內容簡介 二、具體內容 1. 中文分詞的基本概念 2.關於NLPIR(北理工張華平版中文分詞系統)的基本情況 3.具體SDK模塊（C++）的組裝方式 ①準備內容： ②開始組裝 三.註意事項 1. 中文分詞的基本概念 2.關於NLPIR(北理工張華平版中文分詞系統)的基本情況 3.具體SDK模 ...
  • 類與對象1
    類是一個函數包，類中可以放置函數和變數。就像用 def 語句定義函數一樣，用 class 語句來自定義一個類 1. 使用語法 在類中被定義的函數被稱為類的【方法】，描述的是這個類能做什麼。我們使用 Class.function() 的格式 在類中被定義的變數被稱為類的【屬性】，使用的 Class.v ...
  • CC-Python-數據類型之list，tuple
    1，list，列表 列表使用中括弧[]表示，內可盛放各種數據類型如 1(整形)，'abc'(字元串)等等 Ⅰ.列表的增 1、append() append是在列表最後面添加元素 2、insert() 在指定索引處插入新元素 insert(索引,新元素) 如果索引超出列表上界或下屆，則在開頭或結尾添加 ...
  • 高壓電工-覆審
    覆審-理論： 1～歐姆定律指出在一個閉合電路中當導體溫度不變時通過導體的電流與導體兩端的電壓成反比與其電阻成正比對嗎？ 答：歐姆定律指在同一電路中，通過某一導體的電流跟這段導體兩端的電壓成正比，跟這段導體的電阻成反比,這就是歐姆定律。 基於公式I=U/R，電流是與電壓成正比，與電阻成反比。 ...
  • 軟體工程（2019）第一次作業
    [TOC] 1. 回顧你過去將近3年的學習經歷 1.1當初你報考的時候，是真正喜歡電腦這個專業嗎？   不能說是對專業，而是出於對電腦的興趣。   從初中開始接觸電腦，就對電腦產生了濃厚的興趣，也勾起了我對電腦領域的好奇心。高考結束，填報的志願都是電腦 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類