先前有寫過一篇個人常用的 ASP.NET MVC 自訂 HTTP 回應碼畫面的套路,一切看起來都很好,但是當使用者輸入一些資料,驗證不通過的時候,想要送 400(Bad Request)順便在 Body 中塞入一些訊息回傳給使用者,不做點調整是做不到的。
[創意料理] ASP.NET MVC 在網址不變的情況下,自訂 HTTP 400(Bad Request)狀態碼的回應內容。
- 1555
- 0
- ASP.NET MVC
- 2018-11-04
先前有寫過一篇個人常用的 ASP.NET MVC 自訂 HTTP 回應碼畫面的套路,一切看起來都很好,但是當使用者輸入一些資料,驗證不通過的時候,想要送 400(Bad Request)順便在 Body 中塞入一些訊息回傳給使用者,不做點調整是做不到的。
無論我們是要引用網站的資源,還是做重新導向,除非是外部的資源,不然使用相對路徑絕對是優選,在 ASP.NET 的世界裡面我們用來表達根目錄有人會用 /(Slash)
,有人會用 ~/(Tilde Slash)
,但它們兩個的差別在哪?
如果我們認真要用 ASP.NET MVC 做一個對外服務的網站,直接赤裸裸地爆黃白畫面在使用者面前,實在不是那麼優雅,如果從 Web.config 著手要自訂錯誤畫面的話,那麼 Google 到的答案大致就兩個方向:<system.web>/<customErrors>
及 <system.webServer>/<httpErrors>
。
Html.Action
、Html.RenderAction
、Html.Partial
、Html.RenderPartial
這四種方法都可以協助我們在 View 裡面渲染部分 HTML 內容,網路上針對這四種方式的差異說明大都著重在使用方式,但這次我們往下挖,看看這四種方式做了些什麼事?
程式的生命週期往往比我們想像中的長,通常年紀愈大的程式包袱愈重,後面接手的人肩負的壓力也愈重,如果我們知道有一個字串叫 http://www.xxx.com ,現在因為政策的關係必須改成 https://www.xxx.com ,偏偏 http://www.xxx.com 被到處寫死在資料庫及程式原始碼裡面,除了把寫死的那些找出來改之外,我們還可以怎麼做?
相信很多朋友都有遇到過,我們用 ASP.NET MVC 或 ASP.NET WebApi 做好的標記有 HttpPut、HttpDelete 的 Action,部署到 IIS 伺服器之後,試著去發 Request 卻收到 404、405 的錯誤訊息,除非我們只寫 HttpGet、HttpPost 方法,不然有大於 87% 的機率會遇到,底下就來記錄一下解決的方式。
原先從 ASP.NET MVC 4 開始就有的能幫助我們針對 js、css 靜態檔案做 Bundling 及 Minification 的 BundleConfig 到了 ASP.NET Core 還在嗎?答案是有的,只是換了一種使用方式,大致上還是跟原先一樣有兩個步驟:
但實現細節卻大不相同,我們來看看是怎麼個不同法?
我在之前的專案有使用過 ASP.NET Identity 來幫我做驗證的工作,ASP.NET Identity 的出現為驗證身份的方式帶來了更大的彈性,不過如何使用不是這道菜的重點,這道料理要展現的是,當我們為 Controller Action 做有身份識別的單元測試時,我們要如何偽造不同的身份來滿足測試情境?
軟體廚房開始推出小菜一碟系列,這系列的篇幅不長,但是裡面都會有一言以蔽之的重點,像這篇就是在講我們自訂了一個 ModelBinder,它要怎麼做單元測試?
我們拿[料理佳餚] ASP.NET MVC 自訂 ModelBinder 將宣告為抽象型別的參數反序列化這篇的例子來看一下。
如果我們是真的用物件導向在設計程式,那麼一定會用到抽象類的型別(Abstract Class、Interface),在現今當下的資料交換格式中,JSON 算是大家首選的格式,可是當我們的設計相依於抽象之後,序列化及反序列化就變成一個我們必須特別要處理的點,序列化倒是還好,反序列化就比較頭痛了。