私信我，回覆：學習，獲取免費學習資源包。
長話短說， 作為開發人員經常需要根據條件靈活（過濾+排序）數據庫，不管你是用rawsql 還是EFCore， 以下類似偽代碼大家都可能遇到：
特別是在大數據產品或者物聯網產品中，字段甚多；需要 過濾/ 排序 的字段千變萬化， if/else 寫到死，一邊寫一邊吐。
寫出優雅漂亮的代碼，從移除if/else 開始。
頭腦風暴
從靈活查詢的要求看，每一個字段都有為null 或 不為null 的可能， 以上偽代碼6個字段， 理論上僅過濾字段最終執行查詢時形成的sql 共有2^6= 64種可能， 還不算 靈活的排序字段。
現在我們要寫這麼多if 語法，是因為：
- 在編碼階段，強制判斷字段存在， 並據此組裝 rawsql
- 在編碼階段，強制判斷字段存在，並據此使用lambda強類型 構造IQueryable
為了解決這個痛點， 引入動態Linq，動態Linq的不同之處在於 查詢方法的參數不限於強類型的lamdba表達式，而是可以使用字符串;
使用字符串，意味著我們可在運行時動態決定過濾、排序內容
同時由於我們在服務端可完全抓取QueryString（可一次性組裝動態Linq字符串）， 故動態靈活構建查詢的方案呼之欲出。
編碼實踐
以上面偽代碼業務舉例， 根據條件靈活查詢。
1. nuget引入DynamicLinq：
2. 定義EFCore 查詢實體類：
3. Query集合抓取所有QueryString，列舉字段的方式 判斷字段為null， 並構造查詢
EFCore生成的SQL如下：
ok， That‘s all
以上查詢還可擴展：前端組裝排序字符串(orderStr：Uploadtime descending)通過QueryString傳給API，API通過DyanmicLinq構造靈活的排序字段。
經過驗證，以上過濾和排序都是在SqlServer層面完成的。
移除惡心的 if、else之後代碼是不是看起來更優雅一些。
總結
以上場景相信很多開發者都會遇到，特別是進階到一定水平，移除if/else 的慾望愈加強烈。
再次強化本文 知識點：
DynamicLinq 具備動態形成查詢條件的能力，不再依靠lambda 強類型表達式，而是根據構造的過濾和排序字符串，內部解析成查詢條件。
--------------------2019/9/23 下班前更新--------------------------------------
DynamicLinq 若動態組裝String，確實存在 SQL注入問題， 使用placeholder 可避免。
更新代碼：
來源網絡，侵權聯繫刪除
私信我，回覆：學習，獲取免費學習資源包。
