軟體主廚的程式料理廚房

上一篇文章有提到學著讀或寫 IL Code，對我們在程式執行狀況的掌握，有正向的提昇，那麼其中一種學習方式，就是透過我們平常撰寫的程式碼，看看它編譯出來的 IL Code 長什麼樣子，藉此來理解 IL Code，本篇文章就來介紹兩種查看 C# 編譯出來的 IL Code 的方式。

Windows Forms 的 DataGridView 開啟編輯資料之後，我們就可以在畫面上直接對資料進行修改，預設的統一操作行為是修改完資料之後，按下 Enter 鍵或是離開該儲存格，資料就會更新到綁定的 DataSource 上，就像下面這樣：

但是呢，使用者會希望能在修改之後立即更新到 DataSource，不要再多敲 Enter 鍵或離開儲存格的動作，尤其是 ComboBox，我們來看一下怎麼弄？

這件事情是這樣的，在 ASP.NET MVC 有一個 Display Mode 功能，我們公司把它應用在 AWD（Adaptive Web Design） 機制上，雖然在 ASP.NET Core 被拿掉了，但是我們可以實作 IViewLocationExpander 把它給弄回來，某天發現某個 Mobile 網頁的內容套到了 Desktop 版的 Layout，百思不得其解，最後爬了 ASP.NET Core 的原始碼才知道怎麼回事。

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

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

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