軟體主廚的程式料理廚房

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

這件事情說穿了其實就是用 Babel，平常就有在關注前端技術發展的朋友應該不陌生，Babel 可以將 JavaScript 比較新的語法轉譯成通用的寫法，讓舊版的瀏覽器（例如：IE）可以執行，我們就不需要為了舊版的瀏覽器而捨棄新語法。

_ViewStart.cshtml 在 ASP.NET MVC 就存在了，而 ASP.NET Core MVC 則多了一個 _ViewImports.cshtml，這兩個都會對 View 有全域性的影響，重新來了解一下 _ViewStart.cshtml 及新多的 _ViewImports.cshtml 的作用。

微軟官方部落格在去年發佈了一篇 System.IO.Pipelines: High performance IO in .NET，這個東西高不高效我是比較不出來，但是它著實解決了以往在接收 NetworkStream 時算位置的困擾，用它寫出來的程式碼簡潔清晰許多。

前陣子跟同事聊到 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 一次就行了，我們來看看怎麼做？

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

DIP - Dependency Inversion Principle（依賴反轉原則）說：

1. 高層次的模組不應該依賴於低層次的模組，兩者都應該依賴於抽象介面。
2. 抽象介面不應該依賴於具體實現。而具體實現則應該依賴於抽象介面。

如果是初次接觸到這段說明的朋友可能會有一個感覺，就是裡面每個字都看得懂，但是它在講什麼？要了解 DIP 要先清楚它這邊提到的依賴是什麼？我就以我個人的理解來分享我的心得。

憶起第一次執行自己寫的程式的感動，到現在都還記得，當時用的語言是 VB，在 IDE 上開了一個 Form 拉了一個 Button，按下去之後跳出 MsgBox 顯示 "Hello World"，內心不斷地給自己鼓掌「哇！我也會寫程式了。」，至今有沒有曾經後悔過走這條路已經忘記了，但是程式設計「賜我吃、賜我穿、賜我借錢可以還。」是個事實，講這些跟這篇文章的主題有什麼關係？

開發 iOS 的 App 想上架到 App Store 送審被拒絕個幾次可說是稀鬆平常的，即使我們把 App Store Review Guidelines 讀得滾瓜爛熟，還是有被拒絕的可能，而且被拒絕的理由百百種，有跟 Apple 審核團隊交手過的朋友應該就有 fu，我就我這次 App 送審被 Apple 退件拒絕的經驗做個記錄。