軟體主廚的程式料理廚房

有一些網頁的內容是有時效性的，甚至有一些操作是不可逆的，但是瀏覽器的歷程記錄（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 伺服器回應的內容存起來，我們應該要好好地利用它們來降低伺服器跟網路的壓力。

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