軟體主廚的程式料理廚房

ASP.NET Core 內建的 DI Container 稍嫌陽春了一點，讓我懷念起 Autofac 提供的多種花式註冊方式，我決定把它召喚回來攜手共創未來，ASP.NET Core 2.2 到 3.1 有一些 Breaking Changes，設定方式會有一點不一樣，這邊做個記錄。

在 .NET Core 專案中，如果我們按照過往的習慣，使用服務參考（Service Reference）要參考 WCF 或 Web Service，我們會發現跳出來的畫面很陌生。

會想說 .NET Core 不支援開發 WCF 或 Web Service，該不會微軟連參考的功能也拿掉了？　其實沒有，它只是換了位置。

以往服務參考（Service Reference）只能參考 Web Service 或 WCF，但是在把玩 gRPC 服務的過程中，意外地發現，原來在 Visual Studio 2019 已經可以透過服務參考的方式，為 gRPC 服務自動產生客戶端的程式碼，甚至是 Web API 也可以。

這幾天在把玩著 ASP.NET Core 的 gRPC 服務，正當思索著要怎麼實作 AOP（Aspect-Oriented Programming）時，我就看到了 GrpcServiceOptions 有一個 Interceptors 屬性，看到 Interceptor 這個關鍵字就知道 gRPC 服務天生就支援 AOP 的實作。

gRPC 服務預設會使用 HTTPS，不過這個只有針對 localhost 這個網域名稱，這天我想要將自己的區域網路 IP 指定為 gRPC 服務的端點，好做一些驗證跟測試，於是我就動手修改了 Kestrel 監聽的 IP，使用的是 HTTP 協定，然後就在客戶端收到了這個錯誤訊息。

IOException: The response ended prematurely.

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 來實作，實作之後我必須說，程式碼真的可以少寫一些。