应用程序框架实战二十三:基础查询扩展

　　上面两篇已经作好准备，本文将进行基础查询扩展。当使用了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 != "" )
    queryable = queryable.Where( t => t.Name == name );

　　将输入值与""进行比较并不健壮，如果操作人员在某个查询条件输入框中不小心打了个空格，依然会引入错误查询条件，所以你把代码改造为下面这样。

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应用程序框架公共操作类(六):验证扩展