私信我，回复：学习，获取免费学习资源包。
长话短说， 作为开发人员经常需要根据条件灵活（过滤+排序）数据库，不管你是用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 可避免。
更新代码：
来源网络，侵权联系删除
私信我，回复：学习，获取免费学习资源包。
關鍵字: QueryString 字符串 伪代码
