軟體主廚的程式料理廚房

gRPC 服務底層使用 Protocol Buffers 做為序列化的格式，與我們經常使用的 JSON 格式相比之下，其大小已經小非常多了，如果我們還覺得不夠，想要再更進一步地減少傳輸量，可以啟用 gRPC 服務的壓縮（Compression）機制，讓傳輸的資料量再更少一些。

這天在追查為何 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 要付出什麼代價的角度去切入，提供給各位朋友參考。