軟體主廚的程式料理廚房

先前在 [桌邊服務] 關於 ASP.NET SignalR 連線數限制 這篇文章有提到微軟有推出一個雲端服務 - Azure SignalR Service，順手將之前 ASP.NET SignalR 聊天室的範例改用 Azure SignalR Service，意外地非常簡單。

前陣子跟同事聊到 ASP.NET MVC 傳資料給 View 是用 ViewBag 好還是 Model 好？　Google 了一下，沒有標準答案，既然這樣就自己來研究好了，我是從使用 ViewBag 或 Model 要付出什麼代價的角度去切入，提供給各位朋友參考。

ASP.NET MVC 的 View 預設是 Load on Demand（按需加載），也就是說 View 第一次要 Render 的時候才會去載入跟編譯，這個就會造成一個現象，即使 Web 應用程式已經完成啟動，在瀏覽頁面的時候也是會感覺到一點延遲，尤其 Web 應用程式部署在 Azure App Service 上更為明顯，既然這樣，那我們就在 Web 應用程式啟動時候，把所有 View 載入跟編譯，然後 Render 一次就行了，我們來看看怎麼做？

長期在 ASP.NET 打滾，講到 Cache 第一時間就會想到 Redis、Memcached、... 這種伺服器端的 Cache 服務，但是在 Web 技術領域內還有瀏覽器端的 Cache，如果沒有特別指定，檯面上這些主流的瀏覽器都會把 Web 伺服器回應的內容存起來，我們應該要好好地利用它們來降低伺服器跟網路的壓力。

先前有寫過一篇個人常用的 ASP.NET MVC 自訂 HTTP 回應碼畫面的套路，一切看起來都很好，但是當使用者輸入一些資料，驗證不通過的時候，想要送 400（Bad Request）順便在 Body 中塞入一些訊息回傳給使用者，不做點調整是做不到的。

如果我們認真要用 ASP.NET MVC 做一個對外服務的網站，直接赤裸裸地爆黃白畫面在使用者面前，實在不是那麼優雅，如果從 Web.config 著手要自訂錯誤畫面的話，那麼 Google 到的答案大致就兩個方向：<system.web>/<customErrors> 及 <system.webServer>/<httpErrors>。

Html.Action、Html.RenderAction、Html.Partial、Html.RenderPartial 這四種方法都可以協助我們在 View 裡面渲染部分 HTML 內容，網路上針對這四種方式的差異說明大都著重在使用方式，但這次我們往下挖，看看這四種方式做了些什麼事？

相信很多朋友都有遇到過，我們用 ASP.NET MVC 或 ASP.NET WebApi 做好的標記有 HttpPut、HttpDelete 的 Action，部署到 IIS 伺服器之後，試著去發 Request 卻收到 404、405 的錯誤訊息，除非我們只寫 HttpGet、HttpPost 方法，不然有大於 87% 的機率會遇到，底下就來記錄一下解決的方式。

這篇講的是 AngularJS 1.x，寫文章的當下 AngularJS 2.0 已經 RC5 了，已知 AngularJS 2.0 是不會向下相容 1.x 的。

那我為什麼還要寫 AngularJS 1.x 的文章呢？ - 用來幫助我回憶的！

以前花時間閱讀跟學習的技術，隨著時間以及很少用到，記憶會慚慚淡化，趁現在還記得幾分趕快做個筆記，尤其是技術背後本身的概念及限制，這些都會影響到我們掌握一門技術的程度。

我在之前的專案有使用過 ASP.NET Identity 來幫我做驗證的工作，ASP.NET Identity 的出現為驗證身份的方式帶來了更大的彈性，不過如何使用不是這道菜的重點，這道料理要展現的是，當我們為 Controller Action 做有身份識別的單元測試時，我們要如何偽造不同的身份來滿足測試情境？