本來閑來無事，準備看看Dapper擴展的源碼學習學習其中的編程思想，同時整理一下自己代碼的單元測試，為以後的進一步改進打下基礎。 突然就發現問題了，源碼也不看了，開始改代碼，改了好久。 測試Dapper.LiteSql數據批量插入的時候，耗時20秒，感覺不正常，於是我測試了非Dapper版的Lite ...
本來閑來無事，準備看看Dapper擴展的源碼學習學習其中的編程思想，同時整理一下自己代碼的單元測試，為以後的進一步改進打下基礎。
突然就發現問題了，源碼也不看了，開始改代碼，改了好久。
測試Dapper.LiteSql數據批量插入的時候，耗時20秒，感覺不正常，於是我測試了非Dapper版的LiteSql的批量插入，僅需100毫秒，速度差了200倍。
同樣的資料庫、同樣的Npgsql.dll、同樣的測試代碼，產生的SQL和參數集合也是一樣的，最後不得不懷疑Dapper。
引用Dapper的源碼，修改調試之後，我決定提個PR。我之前沒想過提PR，我想我也不是為了提PR而提PR，我也不想費時費力。
沒想到提PR的過程很不順利，原來提的PR需要單元測試全部通過才行。
我本機沒環境不方便測，不過我發現提交申請之後，GitHub上立馬自動編譯測試，能看到哪些單元測試對了，哪些錯了，真強大，真方便，原來大工程是這樣的。
先是提交了一行代碼，認為沒有問題，結果被打了個叉。仔細一看才發現，原來是單元測試不通過。
改了又改，有幾個存儲過程相關的單元測試總是不通過。
都快要放棄了，後來想到是不是我定義的cleanNames變數隨著DynamicParameters類的創建，又清空了，但cleanNames又不能定義成全局的。後來我加了幾行代碼。
一共提交了12次，單元測試終於全部通過，共增加了11行代碼。
PR是提交了，是否被採納就不知道了。也許代碼寫的比較挫，也許審核人員不認可我對Dapper的這種用法，是我用錯了，沒有修改的必要。
修改DynamicParameters.cs文件
變數定義：
private readonly HashSet<string> cleanNames = new HashSet<string>();
單元測試始終無法全部通過，我添加了下麵幾行代碼，終於成功了。原來cleanNames被重新new了之後，command.Parameters里可能是有值的，它的作用域更大一些。
foreach (IDbDataParameter param in command.Parameters)
{
if (!cleanNames.Contains(param.ParameterName))
{
cleanNames.Add(param.ParameterName);
}
}
關鍵的修改就一行
原代碼(參數很多時性能不行，參數什麼情況下會很多呢？就是通過一條SQL批量Insert時會有很多參數，我是500條數據插入一批，參數根據表欄位多少可能有幾千個)：
bool add = !command.Parameters.Contains(name);
當command.Parameters中有幾千個參數的時候，性能就慘不忍睹了。
集合查找的時間複雜度是O(N)。(原來我寫的是O(N/2)，現更正為O(N))
修改為(HashSet性能很高)：
bool add = !cleanNames.Contains(name);
通過HashSet查找，時間複雜度是O(1)。
往cleanNames中添加欄位名：
if (add)
{
command.Parameters.Add(p);
cleanNames.Add(name);
}
總結
-
關於List集合的Contains方法
當你使用Contains方法的時候，你要考慮這個集合有沒有可能突然變的數據量很大？如果是在迴圈中頻繁調用，並且List的數據量比較大，它的性能就比較差，建議使用HashSet或Dictionary來判查找。
但是HashSet、Dictionary和List轉來轉去也有代價，IDbCommand介面的Parameters屬性的類型是IDataParameterCollection，它是一個集合，並沒有HashSet或Dictionary類型的屬性，又必須要轉換才能得到。
提的issue和PR
issue：https://github.com/DapperLib/Dapper/issues/1817
PR：https://github.com/DapperLib/Dapper/pull/1816
LiteSql源碼
LiteSql源於DBHelper，裡面的介面是做過實際項目的，主要是ERP、CRM系統。
簡單支持了Lambda表達式、增加了SqlString之後，使用上似乎變複雜了一點，不過原來的使用方式依然支持。
也許這裡面的介面和設計思想，體現的是我上家公司的前輩們的技術水準。比如實體類用partial修飾分成兩個文件，可能有利有弊吧。自動生成的Model類是不建議修改的，否則資料庫變動的時候你還怎麼自動生成？不把你的改動衝掉了？
一個ORM有它的設計思想和理念，比如DapperExtensions就不建議對實體類加特性，而是通過獨立的映射類來處理表、欄位別名，優缺點我還不清楚。
LiteSql的後續改進，還沒有新的指導思想，所以一直都是小改，基本沒怎麼動。
https://gitee.com/s0611163/Dapper.LiteSql
https://gitee.com/s0611163/LiteSql
即使是大名鼎鼎的Dapper我依然不放心，所以保留了ADO.NET的版本。
