一,前言

現實業務當中,有一個很常見的流程:從資料庫獲取資料到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>”這一流程的業務程式碼已經優化完畢,使用時只需要一行程式碼即可達到目標。

當然,現實中的業務流程肯定千奇百怪,複雜性也不盡相同。本篇文章只是提供一個優化業務程式碼的思路,以及在特定情況下,可以直接套用本文程式碼,以節省開發時間,提高開發效率。

感謝閱讀,歡迎大家評論指正!