编写优雅代码，从挖掉恶心的if/else 开始

长话短说， 作为开发人员经常需要根据条件灵活（过滤+排序）数据库，不管你是用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 可避免。

更新代码：

来源网络，侵权联系删除