軟體主廚的程式料理廚房

這天在追查為何 A 客戶的訂單會出貨到 B 客戶哪裡去？　於是我看到了下面這段程式碼：

在 Login 的 Action 上面被加了 OutputCacheAttribute，Duration 屬性被設成 3，其中還用到了 VaryByParam 屬性，我猜寫這段 Code 的工程師應該是想要為每個登入的帳號做 OutputCache，這樣設定沒有問題，問題出在 HTTP Request 的發送內容。

gRPC 全名叫 gRPC Remote Procedure Calls，是一個由 Google 開發的 RPC 框架，基於 HTTP/2 協定及 Protocol Buffers 序列化協定設計而成的，主打著高性能、跨平台、跨語言（這一點頗吸引我），我們可以將 gRPC Host 在 ASP.NET Core 上做為一個服務發佈出去。

有一些網頁的內容是有時效性的，甚至有一些操作是不可逆的，但是瀏覽器的歷程記錄（History）卻會逆轉這些特性，在使用者按下「上一頁」的那一刻，不該出現的卻出現了、不該消失的卻消失了，怎麼會這樣？

先前有寫過一篇文章 - 將 ASP.NET MVC 的 View 依使用者角色來拆分可以減少邏輯分支，在留言中 demo 哥有提到用 Display Mode 也可以漂亮地解決，於是我就試著把這樣的需求用 Display Mode 來實作，實作之後我必須說，程式碼真的可以少寫一些。

各位朋友應該都有碰過一種需求，就是有一個頁面，這個頁面服務的是廣大的 User，在這群廣大的 User 中有分好幾群，有的群要顯示這個不能顯示那個、有的群要顯示那個不能顯示這個、...，這是很典型的需求，你我的公司裡面應該都存在著這樣的頁面，而且裡面的 if...else... 錯綜複雜，我們冷靜想想，其實這種需求的設計是可以更簡單的。

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

在 twMVC#34 聽到一位朋友說他遇到 ASP.NET SignalR 有連線數 11 的限制，由於這位朋友沒有現身，不知道更詳細的情況，我就我之前遇到的情況跟各位朋友分享，ASP.NET SignalR 是會有連線數限制的情形，但這不是 ASP.NET SignalR 的問題。

前陣子跟同事聊到 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 伺服器回應的內容存起來，我們應該要好好地利用它們來降低伺服器跟網路的壓力。