私信我,回覆:學習,獲取免費學習資源包。
長話短說, 作為開發人員經常需要根據條件靈活(過濾+排序)數據庫,不管你是用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 可避免。
更新代碼:
來源網絡,侵權聯繫刪除
私信我,回覆:學習,獲取免費學習資源包。