Linq to Entity经验：动态查询

上篇文章(Linq to Entity经验：表达式转换)我分享了在使用Ling to Entity时，遇到的一个表达式转换问题，其主要解决的是让UI层调用数据查询时能够实现最大程度上的封装,使得我们的业务逻辑层在处理数据查询时更为精简，不再需要每一个条件写段逻辑。这篇我来总结下我们项目是中如何处理动态条件查询的问题。

问题：

如何解决动态条件查询，而继续保证业务逻辑层的稳定性？
场景：

搜索学生信息，我们可能按学号搜索，也可能按姓名搜索，还有可能按班级搜索，当然也有可能是其它条件，最复杂的情况是同时按多个条件查询。

传统解决方案：

遇到这种情况，基本上有两种类似的方法：

1:拼接动态SQL
因为不知道查询条件，所以可以采用拼接SQL字符串的形式来完成，它的缺点如下：
缺点一：需要注意SQL注入，尽管我们可以采用参数化来解决。
缺点二：需要人工去做这件事情。
缺点三：这样的需求多了，也会大大增加程序员的工作量。

2:大的通用性存储过程
在存储过程中定义多个参数，然后在存储过程内部判断使用哪些条件，这个方案也有缺点：
缺点一：程序中需要写大量这种有动态条件查询需求的存储过程，且逻辑相对复杂。
缺点二：存储过程有自身的一些缺点，这里就不多讲了。

解决方案：

充分利用表达式树的作用来动态构建查询条件，以保证业务逻辑层的稳定性，减轻工作量。

下面是我们业务逻辑层的查询接口方法:

IList<ObjectModel.ActionInfo> QueryByPage<TKey>(Expression<Func<ObjectModel.ActionInfo, bool>> filter, Expression<Func<ObjectModel.ActionInfo, TKey>> orderBy, int orderType, int pageSize, int pageIndex, out int recordsCount)

优点：
1：无论UI上的条件是什么，只要在UI层构建好查询表达式，业务逻辑层的查询接口是不需要变更的。
2：避免在条件中使用字符串，之前提到的两种方法都需要传递条件以确定最终的表字段信息，这是极其不高明的。
3：基于Linq式的查询，使得程序员更加容易理解及接受。

注意：
这里定义的查询接口，是以一张主键为基础的，只要定义好相关的关联表，无论怎样复杂，此接口都不需要额外编写方法。
比如有一个学生表：Student,学生表有一个外键列ClassId，对应的是班级表，我们可以这样写查询：if(班级!="") p=>p.Class.Name=="初二2008班" 即查询初二2008班所有学生信息。但它不能解决某些特别复杂的查询.需要按情况来决定。

调用示例：

这里先看下最终的效果。我们可以定义And,还可以定义Or，如果有需要还可以扩展其方法。

Expression<Func<AllocationPlan, bool>> predicate = p => p.IsActive;
if (planCondition.Project != 0) { predicate = predicate.And(c => c.ProjectId == planCondition.Project); }
if (planCondition.PlanType != 0) { predicate = predicate.And(c => c.AllocationTypeId.Value == planCondition.PlanType); }

方案原理：
将两个表达式合并在一起，其实无论如何组织条件，超不出两类常见的表达式:
1:And,对应SQL中的=，比如Where Name="Tom",它可以将多个条件And在一起变成 Where Name="Tome" and ClassId=1
2:Or,对应SQL中的or,比如 Where EmployeeId=0 or EmployeeId=2

这里不讨论SQL中的一些高级函数用法，只解决常见问题,下面是一老外写的，能够很好的解决动态条件查询时的表达式创建问题，可供参考：

public static class PredicateBuilderUtility
{
public static Expression<T> Compose<T>(this Expression<T> first, Expression<T> second, Func<Expression, Expression, Expression> merge)
{
// build parameter map (from parameters of second to parameters of first)
var map = first.Parameters.Select((f, i) => new { f, s = second.Parameters[i] }).ToDictionary(p => p.s, p => p.f);
// replace parameters in the second lambda expression with parameters from the first
var secondBody = ParameterRebinder.ReplaceParameters(map, second.Body);
// apply composition of lambda expression bodies to parameters from the first expression
return Expression.Lambda<T>(merge(first.Body, secondBody), first.Parameters);
}
public static Expression<Func<T, bool>> And<T>(this Expression<Func<T, bool>> first, Expression<Func<T, bool>> second)
{
return first.Compose(second, Expression.AndAlso);
}
public static Expression<Func<T, bool>> Or<T>(this Expression<Func<T, bool>> first, Expression<Func<T, bool>> second)
{
return first.Compose(second, Expression.Or);
}
}

这里有一个需要特别注意，就是多个表达式中的参数问题，有的时候将多个表达式合并在一起后，虽然程序中看起来没有什么问题，但当EntityFramwork执行数据库查询时会提示：参数p没有绑定之类的异常信息，它的目的就是统一多个表达式中的参数p。
比如:
表达式1:Expression<Func<AllocationPlan, bool>> predicate = p => p.IsActive;
表达式1:Expression<Func<AllocationPlan, bool>> predicate2 = p => p.Id>0;
某些情况下我们需要将上面两个表达式合并成一个,然后调用数据库查询，处理不当就会出现上面的错误。

public class ParameterRebinder : ExpressionVisitor
{
private readonly Dictionary<ParameterExpression, ParameterExpression> map;
public ParameterRebinder(Dictionary<ParameterExpression, ParameterExpression> map)
{
this.map = map ?? new Dictionary<ParameterExpression, ParameterExpression>();
}
public static Expression ReplaceParameters(Dictionary<ParameterExpression, ParameterExpression> map, Expression exp)
{
return new ParameterRebinder(map).Visit(exp);
}
protected override Expression VisitParameter(ParameterExpression p)
{
ParameterExpression replacement;
if (map.TryGetValue(p, out replacement))
{
p = replacement;
}
return base.VisitParameter(p);
}
}

总结：
有了表达式合并的工具类，再结合仓储接口，我们可以写出简单容易理解动态条件查询的程序，也解决了其它传统方案的一些缺点，但这种方案自身也可能有自身的适用场景，适用自身项目的就是最优的，这是我的座右铭。