一，前言
現實業務當中，有一個很常見的流程：從資料庫擷取資料到DataTable，然後将DataTable綁定到實體類集合上，一般是List<Class>，代碼寫起來也簡單：周遊+指派就可以了。
但是，代碼邏輯雖然簡單，代碼量不小，而且代碼往往很臃腫。本篇文章就來一步步對這種業務代碼進行優化。
本文使用C#進行實作及示範。
相信看完的你，一定會有所收獲！
本文位址：https://www.cnblogs.com/lesliexin/p/15307862.html
二，基礎寫法
就像前言所說，代碼邏輯很簡單——周遊+指派，我們來看一下最基礎的寫法。
看起來還好，但是，DataTable是存在空值情況的，而空值在實際業務中是個很嚴重的存在，是以我們需要對DataTable中的空值進行判斷。改造後的代碼如下：
如果沒經曆過太多業務代碼的讀者可能覺得這樣看起來也還好，這是因為我為了示範，隻設計了幾個字段，但在實際業務中，往往都是幾十個字段，甚至上百個字段，而且字段名也不是就“AAA”這樣三個字母，而是十幾、二十幾個字母；當寫出來時，好幾頁螢幕都是這種代碼，别提有多刺激了。
而且，這裡示範時所有屬性字段都是string類型的，現實中肯定不是這樣，會有int，double，Datetime，bool等等類型，那樣代碼量會“更勝一籌”，這點在下文會講。
三，第一步優化
看了上面的代碼，可以發現，絕大部分代碼都是重複的三元判斷，是以在實際寫代碼時，我都是用Excel的下拉複制功能去寫的^_^
我們第一步的優化，就是将這個三元判斷優化掉，方法是使用擴充方法，在擴充方法裡實作三元判斷，并傳回我們需要的值。
我們建立一靜态類，并建立一擴充方法如下：
有了擴充方法後，我們的代碼就可以改成下面這樣：
立馬簡潔了好多有不有！
四，第二步優化
就像上面所說的，不可能所有的屬性字段都是string類型的，會有int，double，Datetime，bool等等類型，這就涉及到類型轉換的問題。加上類型轉換後，不管是使用Convert還是TryParse，代碼就又會臃腫了起來。
是以，我們要将這些類型轉換給優化掉，優化的方式同樣是采用擴充方法，将類型轉換包含在擴充方法中。
使用了擴充方法後，代碼相較之前前簡潔了不少。
五，第三步優化
這時候，我們發現了另一個問題，就是擴充方法太多了。
而且，可以預見的是，随着屬性類型的增多，肯定要編寫對應的擴充方法，比如：StrToInt()，StrToLong()等等。
同時可發現這些類型轉換的擴充方法都是一樣的邏輯，是以我們這一次就優化類型轉換的擴充方法。
我們建立一個泛型擴充方法，以支援将string轉換成指定類型。
這樣下來，所有類型轉換的擴充方法就變成這一個擴充方法，在使用時隻需要寫上對應的類型即可。
六，第四步優化
這種時候，有小夥伴就要問了，既然都是依次調用這兩個擴充方法，那能不是将這兩個再合并一下？當然可以！
我們再改造一下擴充方法，将這兩步合而為一。
這種時候，指派的代碼就變成成了這樣。
一切仿佛發生了改變，一切又仿佛從未改變。
七，第五步優化
一般而言，到第四步時，已經足夠優化了，使用起來也足夠簡單，代碼邏輯也清晰，但是，這還不夠，因為還要重複的去一行一行的指派，都是一樣寫法，就不能優化掉嗎？！
是以這一步我們就将這些給優化掉。
這裡面涉及到兩個重點，一個是擷取類裡的屬性資訊，包含屬性名和屬性類型；一個是擷取DataTable中相應的值并轉換為相應的類型。
同時，因為存在屬性名與列名一樣但大小寫不同的情況，也需要進行判斷。
實作了這個擴充方法，指派部分的代碼就可以簡化成一行代碼。
很驚豔是不是？原來要寫很多行的代碼，現在一行就搞定了，很舒服有不有！
八，第六步優化
什麼？還要優化？還能優化？當然可以！
上面的優化隻能針對屬性名與列名一緻的情況，當屬性名與列名不一緻時，怎麼辦？
而這，就是我們這一步優化的目标。
為了解決屬性名與列名不一緻的問題，我們需要用到特性标簽，我們建立一個特性類，裡面包含一個屬性，用來指定屬性名所對應的列名。
同時，我們改造下上一步的擴充方法ToList<T>，增加對特性标簽的擷取與判斷。
使用時，在實體類上添加上特性标簽即可，比如類的屬性“AAA”要取DataTable中列“FFF”對應的值，則在屬性“AAA”上加上特性标簽“[DT("FFF")]”，其它不需要作任何改變。
九，結束語
至此，經過六步的優化，“從資料庫擷取資料到DataTable，然後綁定到List<Class>”這一流程的業務代碼已經優化完畢，使用時隻需要一行代碼即可達到目标。
當然，現實中的業務流程肯定千奇百怪，複雜性也不盡相同。本篇文章隻是提供一個優化業務代碼的思路，以及在特定情況下，可以直接套用本文代碼，以節省開發時間，提高開發效率。
感謝閱讀，歡迎大家評論指正！