前言
不管是前端，還是后端，做數據合法性驗證是避免不了的，這邊文章就記錄一下Asp.NetCore3.1 WebApi中的模型驗證；
傳統寫法--不使用模型驗證
來，先上圖：
我相信，應該絕大多數人都這樣寫過，反正我是，現在有時候也寫，不是說這樣不行, 根據業務場景進行評估，看是否合適； 這里就那用戶維護新增舉個例；如上圖， 判斷參數合法性一堆，這顯得這個接口方法比較臃腫；
使用模型驗證
先上圖
首先在參數模型上打上注解
接口方法優化
如上圖，是不是看着這個方法比較清晰了，沒那么臃腫了，代碼量似乎也就減少了，出Bug的概率是不是也降低了，哈哈；
調用結果，我這里什么都沒傳，返回400及校驗消息(消息可以自定義)
如上圖，當參數都為空時，在沒進Action之前就被攔截了，並且返回400和校驗的錯誤消息， 這是.NetCore自動校驗了，我們可以將其關閉，讓訪問到Action中來，如下：
在運行進行API調用，同樣傳遞不合法參數，這下就會走到Action中了，如下：
顯然，通過這樣的方式，可以管控到驗證結果，並根據驗證結果返回對應信息，但是，這樣會需要在每個控制器中需要驗證的Action方法中進行判斷和處理，這無疑使得代碼的復用性不好，寫重復的代碼，所以我們需要自己控制模型驗證結果，又要保證代碼整潔的需求下，我們通常自定義中間件或過濾器的方式進行請求攔截處理。下面用過濾器的方式進行處理。
使用Action過濾器
首先定義一個消息返回類，用於所有接口消息規范返回格式，當然，這不是必須的；
/// <summary>
/// 公用的返回消息格式
/// </summary>
public class ReturnMsg
{
/// <summary>
/// 返回的Code
/// </summary>
public string Code { get; set; }
/// <summary>
/// 消息
/// </summary>
public string Msg { get; set; }
/// <summary>
/// 返回的數據
/// </summary>
public string Data { get; set; }
}
然后自定義Action過濾器，我在.NetCore3.1環境下實現，使用的是Attribute的形式。
public class ModelValidateActionFilterAttribute : ActionFilterAttribute
{
public override void OnActionExecuting(ActionExecutingContext context)
{
if (!context.ModelState.IsValid)
{
//公共返回數據類
ReturnMsg returnMsg = new ReturnMsg() { Code = "-1" };
//獲取具體的錯誤消息
foreach (var item in context.ModelState.Values)
{
//遍歷所有項目的中的所有錯誤信息
foreach (var err in item.Errors)
{
//消息拼接,用|隔開，前端根據容易解析
returnMsg.Msg += $"{err.ErrorMessage}|";
}
}
context.Result = new JsonResult(returnMsg);
}
}
}
之后要使用Action過濾器，使用方式有很多種，如全局，控制器，Action上；這里采用的是全局的形式使用；
現在就加上了，現在如果在過濾器中驗證不通過，是不會走到具體的Action方法中的，運行結果如下，按我們定義的消息格式返回了
這樣我們就不用在每個Action中都進行判斷了；當然，消息內容我們是可以自己定義的，只需要在模型上注解時加上就行，如下：
再看運行結果：
總結
項目中我引入了swagger，方便進行測試，不知道的可以找度娘解答； 也可以直接用其他接口調試工具，不需要swagger，如Postman等。