黃忠成

因Dreams.idv.tw網站掛掉,文章範例將無法下載,
由於檔案眾多,我沒太多時間一一修復,若你需要下載特定檔案,請於此文處回應,

在擔任技術顧問時最常遇到兩件事，一件是系統架構調整，另一件則是最大化產品價值，前者是用來維護、奠定日後的發展，後者則是在面對競爭者。一般來說，多數的產品在開發初期就會有假想敵，如果你遇到的是沒有假想敵的產品，那麼恭喜你，你拿到了商業模式中最有利的籌碼，就是稀缺性，但不幸的是，這樣的機率很低，在這個年代，多數的商業模式都已經被找出來，差別在於執行細節及價值的定義。本篇文章以 Dapper 做為假想敵，將追趕它的最有價值部分做一個紀錄，結果其實不是那麼重要，過程才是有趣的部分。

前陣子看到許多朋友轉載這篇關於如何使用C# 快速建立物件實體的文章

在幾年前，我寫過一篇 Dynamic Proxies in C#，內容是透過Interface、Proxy的方式置換虛擬函式，這是許多Mock Library用的手法，事實上除了這個手段外，還有另一個可以達到類似效果的技巧，那就是透過JIT 引擎，用更粗暴的方式來置換IL Code，跟Dynamic Proxies手法不同的是這個方式是針對函式本身，可以影響到靜態與非虛擬函式。

.NET Core 從2016 年發展至今四年了，前陣子的.NET Core 3.0補上了Windows Forms、WPF桌面應用程式支援，讓其應用範圍擴及桌面應用程式，接著的preview 6 則帶來了ReadyToRun的部署模式，這是一個類似.NET Framework NGEN的技術，用來加快.NET Core應用程式的啟動效能，結合preview 5的單一執行檔模式，可以編譯出單一執行檔，又有更好啟動速度的.NET Core 3.0 程式。

每隔一段時間，偶而就會聽到一些靜態函式的都市傳說，比較誇張點的是非靜態函式(也就是類別成員函式)，會依據物件而複製，所以占用記憶體較多。較為貼近合理情況的是靜態函式的執行速度優於非靜態函式，如果你相信我的話，以下就是答案。

.NET Core 第一次 (2016/6) 出現，到第一版的 RC 1(2016/9)，至今已過了兩年，正式版本號也推進到了 2.2，前兩個主要版本開發標的均聚焦於跨平台與 Server-Side(ASP.NET)的支援，隨著基礎建設 (BCL)的日趨完善，.NET Core 3.0 開始轉移開發焦點至 Desktop部分，納入了 WPF、WinForm、UWP，還有 Entity Framework 6。也就是說未來的 .NET Core 3.0可以取代 NET Framework來進行 Windows GUI的開發，以目前披露的訊息及實作來看，GUI 的部分依舊是維持在 Windows平台上，不具備跨平台的能力。

Entity Framework是一個相當易用的ORM Framework，但偶而卻無法滿足最簡單的需求，原因是其有其設計的主軸，不該出現的設計所產生的需求，通常不在其考慮的範圍內，在顧問及授課生涯中，常常出現一些需要滿足，卻又不符合常態的需求，例如本文提及的string to int就是常見的問題。

  多數的O/R Mapping Framework都有個共同的行為模式，在刪除資料或是修改資料前，必須隱式的下達一個Query，由資料庫取得即將要更新的資料列，然後轉成物件後再更新。  這個行為模式，多半也會成為設計師考慮是否使用O/R Mapping Framework的考量之一，因為多一個Query，就代表著效能會因此降低，雖然對於O/R Mapping Framework而言，這是一個必要的行為模式，因為它們得考量到當物件有著關聯時的情況。但對於實際的專案來說，跳過這個Query來更新資料，卻也是必然會出現的情況，既然是必然會出現的情況，多數的O/R Mapping Framework也只好為此做出讓步，提供可跳過Query來更新資料的機制，Entity Framework自然也擁有這個機制。

  當一個地雷踩第二次的時候，就是以文字記錄下來的時候。

  說好要解答的，所以就來吧，這是當下最佳解，以後搞不好我有新的解法也不一定。

  這兩年，我在設計課程時改變實作的方式，只給問題不給答案讓學員自己思考實作，最後再給答案來討論，就效果而言，其實蠻不錯的，因為有思考，知識就會著床，唯一較難調適的是我不知道在旁邊閒著要幹嘛，常常忍不住就丟答案出來了，以後我看帶PS4去打恐龍好了。這篇文章就因應這種方式而寫的，分成兩部分，第一部分是給問題，這裡我整理了11個LINQ的問題，聚焦在LINQ To Objects，不包括LINQ To Entity Framework或是其它，第二部分則是答案及探討，基本上我希望在你看第二部分前已經用自己的思考得到答案，接著驗證自己的答案，最後再看第二部分，當然，如果你挑出第二部分的答案有問題，我也是非常歡迎的(敬禮)。值得一提的是，在設計這11道題目時，我刻意地避免為了考倒你而出題，所以沒有刁鑽的問題，也沒有陷阱題。(我多用了兩顆CPU想，所以要提一下)，第二部分會在連假結束後貼出。

LINQ 的設計初衷就是放在程式設計師日常都會用到的功能上，藉此節省程式碼的量，身為C# 工程師，我們在解搜尋、排序、過濾這些問題時，應該時時刻刻都要想到如果運用LINQ，是否會有更好的解法，
本系列文便是一個紀錄，我沒有定任何的週期發布時間，純屬遇到後，就記錄下來，也不代表是最好的解法，你知道，這世界上只有當下最佳解，如果你有更好的解法，歡迎分享 ^_^ ，若對這系列有興趣，可以追蹤本粉絲頁。

C# 並不是唯一一個提供語法糖的程式語言，但卻是少數敢持續在新版本中加進數量堪稱大量語法糖的語言，單以語法糖這點來說，C# 算是發揮得相當極致。

  最近的Windows 10 Fall Creators Update更新中，提供了一樣以往被視為是難以取得的的資訊，那就是GPU的使用率及記憶體用量，這以往都要靠特定的工具才能查看，例如GPU-Z或是Riva Tuner，如果是NVIDIA那就還好，NVIDIA會在資源監視器中添加幾個計數器，所以取得其實不困難，但如果是ATI/AMD甚至是Intel HD，沒有特定的通道與知識是很難達到取得這些資訊的，尤其是記憶體(Video Memory)用量，在這次的更新後，這一切都變得非常簡單了。

SIMD是Single Instruction Multiple Data的縮寫，通常中文翻譯為單指令多數據流，用較白話的說法是，同時對多個數據執行同一條CPU指令，達到平行運算的目的。

隨著Visual Studio 2017，C# 正式來到7.0，這一版與6.0一樣，並沒有特別的主軸，只在語法上做改動，期望達到更直覺、清楚的程式碼設計風格。

如果沒看過上集，記得要看一下哦。這篇文章主軸介紹C# 6.0新增的擴展行為。

這是2011年 談C# 編譯器編譯前的程式碼擴展行為 的續篇，當年該文章由C# 1.0討論到4.0，中間也過了好多年，今年終於興起來寫個續篇了，如果你沒看過前篇，建議看這篇前先瀏覽一下，該文中提及的東西至今仍然未過時，語言的東西不比特定技術，很少會發生Breaking Changes或是整個Feature移除，頂多只是改善。

軟體需求總是不停地在改變，有些時候需求帶著UI，有些時候需求則可以排除UI，端看使用者的角色而定。會有這篇文章的原因是最近收到了一個很特別的需求，這個需求的受眾，也就是使用者其實是公司內部的PM、工程師，所以UI不一定需要很複雜，甚至不太需要UI，因為牽扯到實際商業行為，以下我便用類似的假想型需求來呈現。