基础查询扩展
上面两篇已经作好准备，本文将进行基础查询扩展。当使用了Entity Framework这样的ORM框架以后，我们查询的核心被集中在IQueryable的Where方法上。
如果UI需要通过姓名查询一个客户，会在UI上放置一个输入框作为客户姓名的查询条件。服务端接收以后通过Where方法进行过滤，如下所示，entities表示DbContext的子类。
var queryable = entities.Customers.Where( t => t.Name == name );
当然，也可以使用Linq语句来完成。
var queryable = from c in entities.Customers
where c.Name == name
select c;
这些代码看上去很不错，但不论是上面的扩展方法还是Linq语句，其结果都是错的。如果操作人员正好在查询条件的框中输入了一个“张三”，确实会把名称为“张三”的客户全部找出来，但是如果操作人员什么也不输入，直接点击查询按钮，结果会怎样？
上面的代码会强制引入查询条件，哪怕输入值是空的，这与我们的预期不符，所以大家的办法是添加一个判断，像下面这样。
IQueryable<Customer> queryable = entities.Customers;
if( name != null )
queryable = queryable.Where( t => t.Name == name );
将输入值与null进行比较并不健壮，如果操作人员在某个查询条件输入框中不小心打了个空格，依然会引入错误查询条件，所以你把代码改造为下面这样。
IQueryable<Customer> queryable = entities.Customers;
if(!string.IsNullOrWhiteSpace( name ) )
queryable = queryable.Where( t => t.Name == name );
但是string.IsNullOrWhiteSpace只能针对字符串，对于其它类型需要先调用ToString，代码继续修改。
IQueryable<Customer> queryable = entities.Customers;
if( value != null && !string.IsNullOrWhiteSpace(value.ToString() ) )
queryable = queryable.Where( t => t.XXX == value );
对于非字符串类型的查询条件，为了保障ToString的安全，需要在之前判断是否为null，否则可能抛出null异常。上面的代码比较健壮了，但是非常丑陋，如果只有一个查询条件，这不是大问题，但有10个条件呢？
IQueryable<Customer> queryable = entities.Customers;
if( value1 != null && !string.IsNullOrWhiteSpace(value1.ToString() ) )
queryable = queryable.Where( t => t.F1 == value1 );
if( value2 != null && !string.IsNullOrWhiteSpace(value2.ToString() ) )
queryable = queryable.Where( t => t.F2 == value2 );
if( value3 != null && !string.IsNullOrWhiteSpace(value3.ToString() ) )
queryable = queryable.Where( t => t.F3 == value3 );
......
打开你自己的项目来检查一下，应该和上面代码类似，这些杂乱无章的判断把查询的主题冲淡了。
我上面讨论的是相等（==）运算符，对于像Contains这样的Like查询，它不害怕空字符串“”，但是如果字符串中带了空格“ ”，查询结果也是错的。可见，Where这个核心查询方法，并不适合直接在应用程序中使用，除非你的查询条件是必填项。对于从界面传过来的查询条件基本都是可选的，所以我们有必要进行查询扩展。
以上介绍了扩展Where方法的动机，下面开始进行扩展。
通过上面的示例代码可以看出，每当需要调用where时，都需要进行一个判断，我们的目标就是把这个判断隐藏到框架背后。
首先考虑过滤方法的名称，我命名为Filter，表示这是一个过滤器方法。
再考虑Filter的方法签名，很显然返回类型是泛型的IQueryable<>，那么参数呢？
我最初的做法是提供两个参数，第一个参数是Lambda表达式，第二个参数是查询条件的输入值。之所以需要第二个参数，是因为我当时不清楚怎么从Lambda表达式中把输入值提取出来，方法如下所示。
/// <summary>
/// 过滤
/// </summary>
/// <typeparam name="TEntity">实体类型</typeparam>
/// <typeparam name="TMember">实体属性类型</typeparam>
/// <param name=" queryable">查询对象</param>
/// <param name="predicate">过滤条件</param>
/// <param name="value">属性值</param>
public static IQueryable<TEntity> Filter<TEntity, TMember>( this IQueryable<TEntity> queryable, Expression<Func<TEntity, bool>> predicate, TMember value ){
if (value == null)
return queryable;
if (string.IsNullOrWhiteSpace(value.ToString()))
return queryable;
return queryable.Where( predicate );
}
调用代码如下。
IQueryable<Customer> queryable = entities.Customers; queryable = queryable.Filter( t => t.F1 == value1, value1 ).Filter( t => t.F2 == value2, value2 ).Filter( t => t.F3 == value3, value3 );
可以看到，调用代码比直接使用Where已经清爽多了，不过这个Filter不是完美的，对于值类型的输入条件，结果是错的。比如value1是一个int类型，它的默认值为0，它将逃过string.IsNullOrWhiteSpace的检测。那么我们添加一个条件来检测默认值好不好呢，比如if(value == default(TMember)) return; 。这是不行的，如果你要搜索某字段为0的记录就会失效。
导致这个问题的原因是值类型无法为空，对引用类型没有影响，我的解决方案是强制使用可空值类型。对于查询来讲，一般不会直接传递一个条件参数，因为大部分UI都要求分页，传递多个参数是不方便的。我通过创建一个查询实体来强制实施上面的原则，查询实体拥有一些查询属性，且每个属性都是可空的，并且会帮我过滤掉字符串参数中的空格，待我介绍到应用层的时候再详细说明。
无独有偶，我在园子里看到一篇文章和我上面的查询扩展非常类似，只是他的第二个参数用了bool类型。使用bool类型的好处是更加灵活，当然代价是需要写更多代码。调用代码如下所示。
IQueryable<Customer> queryable = entities.Customers; queryable = queryable.Filter( t => t.F1 == value1, !string.IsNullOrWhiteSpace(value1)).Filter( t => t.F2 == value2, value2 != 0 );
在长时间使用了两个参数的方案后，我感觉非常别扭，我为什么要传入第二个值？直接从Lambda参数中提取出输入值不是更好？下面我们说干就干。
public static IQueryable<T> Filter<T>( this IQueryable<T> queryable, Expression<Func<T, bool>> predicate ) {
if ( predicate.Value() == null )
return queryable;
if ( string.IsNullOrWhiteSpace( predicate.Value().ToString() ) )
return queryable;
return queryable.Where( predicate );
}
这里的关键方法是Value，这个自定义方法是上一篇扩展的，它能够从Lambda谓词表达式中把输入值提取出来。
这个方案与我之前使用的方案类似，只是省下一个参数，它同样需要使用可空值类型。
目前的代码还有一个问题，如果程序员一次传入多个条件，会导致什么结果？
IQueryable<Customer> queryable = entities.Customers; queryable = queryable.Filter( t => t.F1 == value1 && t.F2 == value2 && t.F3 == value3 )
如果value1=”a”,value2和value3是空值，我得把t.F1 == value1拆出来，再传到where中去。当然是可以做到，但太费力，所以我想了个偷懒的方法，一次只允许传递一个条件，一次传入多个条件将抛出异常。
public static IQueryable<T> Filter<T>( this IQueryable<T> queryable, Expression<Func<T, bool>> predicate ) {
if ( Lambda.GetCriteriaCount( predicate ) > 1 )
throw new InvalidOperationException( String.Format( "仅允许添加一个条件,条件：{0}", predicate ) );
if ( predicate.Value() == null )
return queryable;
if ( string.IsNullOrWhiteSpace( predicate.Value().ToString() ) )
return queryable;
return queryable.Where( predicate );
}
GetCriteriaCount是我在上一篇创建的第二个方法，用来获取Lambda谓词表达式中的条件个数，只要大于1个，就会抛出InvalidOperationException异常。
为了保证程序员不会把null传进来，添加一个null检测。
public static IQueryable<T> Filter<T>( this IQueryable<T> queryable, Expression<Func<T, bool>> predicate ) {
predicate.CheckNull( "predicate" );
if ( Lambda.GetCriteriaCount( predicate ) > 1 )
throw new InvalidOperationException( String.Format( "仅允许添加一个条件,条件：{0}", predicate ) );
if ( predicate.Value() == null )
return queryable;
if ( string.IsNullOrWhiteSpace( predicate.Value().ToString() ) )
return queryable;
return queryable.Where( predicate );
}
CheckNull用于检测对象是否空值，如果为null将抛出异常。
上面介绍了Filter方法的封装过程，现在开始扩展Util应用程序框架。
创建一个名为Util.Datas的类库，并添加相关依赖，这个项目用于放置数据相关公共操作。创建Extensions.Query.cs文件，它用来对查询进行扩展，代码如下。
using System;
using System.Linq;
using System.Linq.Expressions;
using Util.Datas.Queries;
namespace Util.Datas {
/// <summary>
/// 查询扩展
/// </summary>
public static class Extensions {
/// <summary>
/// 过滤
/// </summary>
/// <typeparam name="T">实体类型</typeparam>
/// <param name="queryable">查询对象</param>
/// <param name="predicate">谓词</param>
public static IQueryable<T> Filter<T>( this IQueryable<T> queryable, Expression<Func<T, bool>> predicate ) {
predicate = QueryHelper.ValidatePredicate( predicate );
if ( predicate == null )
return queryable;
return queryable.Where( predicate );
}
}
}
检测代码移到一个名为QueryHelper的internal类中，因为我后面还需要用到这段逻辑，代码如下。
using System;
using System.Linq.Expressions;
namespace Util.Datas.Queries {
/// <summary>
/// 查询操作
/// </summary>
internal class QueryHelper {
/// <summary>
/// 验证谓词，无效返回null
/// </summary>
/// <typeparam name="T">实体类型</typeparam>
/// <param name="predicate">谓词</param>
public static Expression<Func<T, bool>> ValidatePredicate<T>( Expression<Func<T, bool>> predicate ) {
predicate.CheckNull( "predicate" );
if ( Lambda.GetCriteriaCount( predicate ) > 1 )
throw new InvalidOperationException( String.Format( "仅允许添加一个条件,条件：{0}", predicate ) );
if ( predicate.Value() == null )
return null;
if ( string.IsNullOrWhiteSpace( predicate.Value().ToString() ) )
return null;
return predicate;
}
}
}
为了让大家可以把Demo运行起来，我还创建了Util.Datas.Ef.Tests测试项目，SqlScripts目录中的Test.sql用来建库，数据库名为UnitTest，之所以不使用Test，是害怕把你本地的Test数据库给删掉了，这个数据库安装在你的D:Data目录中，如果不合适请自行修改。
Samples目录中的Employee类是测试的实体，它非常简单，只有一个Name属性。
Repositories目录中的EmployeeRepository是测试仓储，为了简单，没有创建仓储的接口，因为这里没什么用。
本文的集成测试FilterTest位于QueryTests目录，代码如下。
using System.Linq;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Util.Datas.Ef.Tests.Repositories;
using Util.Datas.Ef.Tests.Samples;
namespace Util.Datas.Ef.Tests.QueryTests {
/// <summary>
/// 过滤测试
/// </summary>
[TestClass]
public class FilterTest {
/// <summary>
/// 测试初始化
/// </summary>
[TestInitialize]
public void TestInit() {
EmployeeRepository repository = GetEmployeeRepository();
repository.Clear();
repository.Add( Employee.GetEmployee() );
repository.Add( Employee.GetEmployee2() );
}
/// <summary>
/// 获取员工仓储
/// </summary>
private EmployeeRepository GetEmployeeRepository() {
return new EmployeeRepository( new TestUnitOfWork() );
}
/// <summary>
/// 测试Filter过滤
/// </summary>
[TestMethod]
public void TestFilter() {
EmployeeRepository repository = GetEmployeeRepository();
//用where查询
var result = repository.Find().Where( t => t.Name == "" );
Assert.AreEqual( 0, result.Count() );
//用Fileter查询
result = repository.Find().Filter( t => t.Name == "" );
Assert.AreEqual( 2, result.Count() );
Assert.AreEqual( Employee.GetEmployee().Name, result.ToList()[0].Name );
Assert.AreEqual( Employee.GetEmployee2().Name, result.ToList()[1].Name );
}
}
}
我在测试中比较了Where与Filter的不同，你可以自己运行一下，如果还不知道如何运行测试，请参考Util应用程序框架公共操作类(二):数据类型转换公共操作类（源码篇）。
当然使用Where查询比较死板，你需要在编译时期固定查询字段和操作符，这对于某些需要更灵活的场景并不合适，不过一般的系统对查询灵活性要求都不高。
本文虽然是针对IQueryable进行扩展，但思路上对于更原始的Ado.Net直接操作Sql同样适用。可以看出，.Net Framework给你提供的API比较原始，如果需要满足自己的需求，就需要扩展你的应用程序框架。另外不要轻视这个小小的扩展和封装，因为你的大多业务都需要查询，如果你有100个模块，每个模块有5个查询条件，能帮你省下500个判断。判断语句不仅枯燥而且容易喧宾夺主，扰乱你的查询主题。
.Net应用程序框架交流QQ群: 386092459，欢迎有兴趣的朋友加入讨论。
谢谢大家的持续关注，我的博客地址：http://www.cnblogs.com/xiadao521/
如果需要下载代码，请参考Util应用程序框架公共操作类(六):验证扩展