軟體主廚的程式料理廚房

微軟官網有一篇 .NET Core 應用程式部署的文章在介紹 .NET Core 的部署模式，只是裡面都是文字，再加上有一些新的詞彙，什麼 FDD、SCD、FDE，看了也懂了，但是實際操作還是有點霧煞煞，我這邊就直接用 Visual Studio 2019 的發佈設定視窗，來說明不同的發佈設定會對發佈結果造成什麼影響？

對我來說寫測試有一個很大的目的就是「保護既有已完善的程式碼」，我開發的 jQuery 擴充套件 - jquery-model 已經被我們團隊成員接受並廣泛使用，為了保護自己也保護他人，是時候為它投入一些時間架設防護網，而 JavaScript 的單元測試框架有好幾款，我選擇了 Jasmine，為啥呢？　因為它在官網的 GETTING STARTED 頁面就告訴我如何用 STANDALONE 的發行版本來引用 Jasmine，僅此而已。

在過往的需求中，難免會有那種需要按照順序產生或處理資料的時候，我個人常用的解法是替資料照著順序給一個可排序的標記，這就需要一個按照順序產生識別碼的機制，如果在同一個應用程式內還好處理，要是跨應用程式、跨機器的話，產生識別碼的演算法就要好好想想，現成的話 SQL Server 就有一個 SEQUENCE 功能可以用。

平常寫最多的程式語言是 C#，這天在寫 JavaScript 的時候想到「JavaScript 有唯讀屬性嗎？」，以前有唯讀屬性的需求時，通常我都是這樣寫：

但是嚴格來講 fullName 是 Function 不是 String，JavaScript 也告訴我它是 Function。

那究竟 JavaScript 有沒有唯讀屬性呢？

在前一篇文章 [料理佳餚] ASP.NET Core 的虛擬目錄哪去了？中有提到，傳統 ASP.NET 的 HTTP Handler 及 HTTP Modules 的工作在 ASP.NET Core 是由 Middleware 來負責處理，這篇文章就來介紹撰寫 Middleware 的幾種方式。

在傳統 ASP.NET 的年代，我們別無選擇，寫好的 ASP.NET 應用程式只能 Host 在 IIS 上執行，其中虛擬目錄的服務是由 StaticFile 這個 HTTP Handler 來負責處理。

而 ASP.NET Core 內建就有 Kestrel 這個輕量化的網頁伺服器，不需要再依賴 IIS，但是脫離 IIS 之後，我們要怎麼設定虛擬目錄？

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 的實作。