軟體主廚的程式料理廚房

Cache 是在 Web 應用程式開發領域，無論前端或後端都需要深入了解的一件事情，良好的 Cache 機制是可以降低網頁的回應時間，以及同時節省後端伺服器的運算資源，其中關乎到 Cache 品質的兩項因素是：新鮮度、命中率，而影響到這兩項因素的關鍵就在於我們的更新策略。

在 C# 應用程式內部要做鎖定，第一時間我們一定是先想到 lock 陳述式，但是 lock 陳述式無法在 async/await 的場景下使用，程式編譯不會通過，我們會得到一個錯誤訊息 - 無法在 lock 陳述式的主體中等候。

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

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

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

由於 CPU 時脈的發展受限，因此 CPU 的發展不再往更高時脈前進，而是往更多核心數前進，隨之而來的，便是軟體設計師需要調整軟體的設計，讓原本的演算法能夠分散執行，充分地利用多核心的資源，使程式執行起來更有效率，而在開發分散式運算應用程式時，我個人是認為應該加入不可變性（Immutability）的設計，來強調其分散式運算的意圖。

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

「鎖定」的使用場景通常是我們希望某個資源，同一個時間只有一個程序來存取它，在同一個應用程式中我們有 lock 陳述式、Monitor.Enter、Monitor.TryEnter 可以用來做鎖定，當有一個以上的應用程式，甚至是跨不同機器的應用程式要做鎖定時，會需要用到額外的資源，我們儘量利用我們手邊有的資源來做這件事。

在這篇文章中網友的留言吸引了我的注意，.NET Framework 提供了至少三種取得檔案目前位置的方法：

• AppDomain.CurrentDomain.BaseDirectory
• System.Reflection.Assembly.GetExecutingAssembly().Location
• System.IO.Directory.GetCurrentDirectory()

我還真不知道它們具體上的差異，趁這個機會做了一下實驗順便記錄下來，也提供給各位朋友參考。

這個雷我踩了不下三次，寫下來記錄一下，C# 程式要取得當前目錄的方法我們下關鍵字搜尋可以搜出一堆解決方案，沒意外的話第一個搜尋結果通常是 Directory.GetCurrentDirectory 方法(System.IO) - MSDN - Microsoft，但是這個方法在程式是由 Windows 工作排程器（Task Scheduler）啟動的狀況下就不 Work 了。

上一篇文章提到依賴，依賴也無所不在，而 DIP 要我們將依賴做「反轉」，是要反轉什麼？反過來依賴嗎？　當然不是，而是解除直接依賴的關係轉而去依賴於抽象介面，使得位於較低層次的類別依賴關係的方向反了過來，大致上看起來就會像這樣。