网站首页 | 最新手游 | 最新软件 |
网站导航
手机游戏
休闲益智 角色扮演 动作冒险 射击枪战 体育竞速 经营策略 MOBA
手机软件
网络浏览 社交聊天 影音播放 学习教育 生活常用 阅读资讯 效率办公 拍照摄影
技术中心
PHP教程 php框架 前端框架 其他 数据库 运维 系统工具 软件教程 手机系统教程
博客中心
数据库 APP开发 电脑问题 编程语言 网络系统 前端开发 互联网
插件下载
输入 banner图 图片脚本 客服 导航分类 播放器 css3 jQuery脚本 jqueryhtml5
源码下载
企业程序 小说有声 网站源码 第三方软件 新闻资讯 第三方源码
电脑软件
聊天工具 视频软件 音乐软件 游戏娱乐 网络游戏 浏览器 图形图像 安全杀毒
电脑软件
输入法 下载工具 股票网银 办公软件 阅读翻译 压缩刻录 系统工具 编程开发
电脑软件
手机数码 教育学习 网络应用 主题壁纸 其他软件 font字体 存储管理 压缩解压
电脑软件
系统设置 改名软件 文本编辑 拼音输入 降温程序 电子阅读 打印工具 刻录软件
电脑软件
翻译软件 系统优化 网页浏览 广告过滤 网站推广 下载工具 FTP工具 邮件收发
专题合集

热搜：蛋仔派对官服版  大话诛仙bt版  懒人听书正式版  mm131纯净版  美剧鸟破解版  

首页 手机游戏 手机软件 软件下载 jquery插件库 程序下载 手机教程 专题
您的位置：首页 > 博客中心 > 数据库 >

Linq to Sql：N层应用中的查询(下) : 根据条件进行动态查询

时间：2022-03-13 22:54

原文:

    如果允许在UI层直接访问Linq to Sql的DataContext，可以省去很多问题，譬如在处理多表join的时候，我们使用var来定义L2S查询，让编译器自动推断变量的具体类型(IQueryable<匿名类型>)，并提供友好的智能提示；而且可以充分应用L2S的延迟加载特性，来进行动态查询。但如果我们希望将业务逻辑放在一个独立的层中(譬如封装在远程的WCF应用中)，又希望在逻辑层应用Linq to sql，则情况就比较复杂了；由于我们只能使用var(IQueryable<匿名类型>)，而var只能定义方法(Method)范围中声明的变量，出了方法(Method)之后IDE就不认得它了；在这种对IQueryable<匿名类型>一无所知的情况下，又希望能在开发时也能应用上IDE的智能感应，我们该怎么定义层之间交互的数据传输载体呢？又如何对它进行动态查询呢？

     内容比较多，分上下两篇，上篇了介绍查询返回自定义实体，本篇介绍动态查询。

 

     在我们的日常开发中，时常需要根据用户在UI上的输入来进行动态查询。在Ado.Net主宰的旧石器时代，一般会这样来动态拼接SQL查询条件：

   6: gridView.DataSource = BusinessLogic.XOXOQuery(filter);

    然后将过滤条件传给业务逻辑层，由业务逻辑层拼接出完整的TSQL语句。  但到了LINQ to SQL时代，我们该办了呢？还要继续玩字符串拼接游戏吗？

    后面将以NorthWind为例，动态查询产品(Product)及其供应商信息(Supplier)： 

   1: partial class ProductExt : Products
   2: {
   3:     public string CompanyName { get; set; }
   4: }

 

1. UI层直接访问DataContext

    如果使用L2S查询延迟加载的特性，动态查询也变得相当简单：

   1: public void TestDynamicQuery()
   2: {
   3:     using (NorthWindDataContext context = new NorthWindDataContext())
   4:     {
   5:         var query = from P in context.Products
   6:                            join S in context.Suppliers
   7:                             on P.SupplierID equals S.SupplierID
   8:                            select new
   9:                            {
  10:                                P.ProductName,
  11:                                P.UnitPrice,
  12:                                P.QuantityPerUnit,
  13:                                S.CompanyName
  14:                            };
  15:         if(XXOO)
  16:             query = query.Where(p => p.ProductName.Contains("che"));
  17:         if(OOXX)
  18:             query = query.Where(p => p.UnitPrice >= 20);
  19:         gridView.DataSource = query.ToList(); //延迟加载，ToList时才进行运算
  20:         gridView.DataBind();
  21:     }
  22: }

    看起来还是比较舒服的，不用再继续拼接SQL了，开发时也可以充分利用IDE的智能感应。

    但也不是无可挑剔，这里的逻辑无法复用。假如另外一个应用场景，要根据供应商名称来查询产品信息，我们该怎么处理呢，另外再写一个查询？如果再多一个引用场景呢，难道我们每次都要Ctrl+C | Ctrl +V？还是把这个逻辑封装在业务逻辑层，让多个的页面都可以使用？

 

2. 分层后引发的问题

    分层的好处之一就是逻辑复用。在Ado.Net时代，我们可以把这个join操作放在业务逻辑层，UI层只需要根据不同的应用场景，拼接where条件，然后传给业务逻辑层处理即可。

    当在分层应用中使用L2S时，如果想把这个逻辑放到业务逻辑层，我们或许可以这样做：

2.1.  继续拼接

    或许我们想过继续按照旧石器时代的做法，直接拼接；但是我们立刻会发现显然是行不通的，我们无法“直接”将L2S查询与字符串进行拼接。

2.2. 构造Expression或者Func

    query.Where()可以接受一个表达式Expression<Func<TSource, bool> predicate>或者委托Func<TSource, bool> predicate，或许我们想过尝试构造这样的Expression或者Func；但是我们又会遇到新的问题，如上面的查询，我们的query的类型是IQueryable<匿名类型>，匿名类型的定义是在编译阶段才由编译器创建的，开发时我们根本不知道TSource是类型，又该怎么创建这样的Expression或者Func呢？

 

3. 使用Dynamic LINQ继续拼接游戏

    上面2.1中提到无法“直接”将L2S查询与字符串进行拼接，但是可以通过一些扩展来间接达到目的，网上已经有人这么做了，具体可以参考：Dynamic LINQ。下面是一个示例：

   1: Northwind db = new Northwind(connString); 
   2: var query =
   3:     db.Customers.Where("City == @0 and Orders.Count >= @1", "London", 10).
   4:     OrderBy("CompanyName").
   5:     Select("New(CompanyName as Name, Phone)");

    看起来，貌似我们又可以继续玩字符串拼接了。不过需要注意的一点儿是，这里拼接的字符串不再是TSQL中的字符串命令了，而是L2S查询。这是基于如下原因：在L2S中，查询被表示为一个表达式目录树(Expression Tree，表示的是数据，不是代码)，待需要访问查询结果集时(针对延迟加载的情况)，这棵树才被对应的Provider(这里用的是SQL Server，所以对应的是SqlProvider)翻译为TSQL，并发送给ADO.Net来执行；Dynamic LINQ就是将传进来的字符串解析为表达式目录树，并与原来的L2S进行适当地合并，从而得到最终的表达式目录树。

    根据字符串进行拼接，是一种解决办法。但是这样做有个不好的地方，就是我们失去了IDE的智能感应。

 

4. 对IQueryable进行动态查询扩展

    上面2.2节中，还提到了另外一种处理思路，那就是构造Expression或者Func；当然，这里会遇到上面提到的问题：我们的query的类型是IQueryable<匿名类型>，开发时根本不知道其具体类型，如何创建Expression<Func<匿名类型, bool> predicate>或者委托Func<匿名类型, bool> predicate呢？

   下面是我实现过程中的那艰苦卓越的辛酸历程：

    还是拿上面的查询作为例子，譬如要查询ProductName.Contains("che")) && UnitPrice >= 20的记录；则我们能构造出来的及需要构造出来的表达式会是什么样子呢？下面是两者之间的差距：

Expression<Func<Products, bool>> predicate = t => t.ProductName.Contains("che") && t.UnitPrice >= 22 //Can Do
Expression<Func<匿名类型, bool>> predicate = t => t.ProductName.Contains("che") && t.UnitPrice >= 22 //To DO

    差距呢？乍一看，这就是一对双胞胎啊，还需要转换个啥子，吃饱撑的啊……
    不过细看之后，二者确有不同之处，下面是补全后的对比：

Expression<Func<Products, bool>> predicate = (Products  t) => t.ProductName.Contains("che") && t.UnitPrice >= 22
Expression<Func<匿名类型, bool>> predicate = (匿名类型 t) => t.ProductName.Contains("che") && t.UnitPrice >= 22

    现在可以看到，这不是一对普通的双胞胎，基因中的软色体都不是一个样子，这是一对龙凤胎。由于.Net是强类型语言，IEnumerable<TSource>.Where()方法只认得后者，而拒绝接受前者，因此接下来，我们的目标是……没有蛀牙？NO，基因手术……当然，也希望手术的副作用包括没有蛀牙(bug)。

 

                                      ------------------我是华丽的分割线(happyhippy.cnblogs.com)--------------------

 

    上一篇中，我实现了一个对象转换器，可以把一个对象转换成另一个对象；但这里用不上，这里需要换的是基因，需要把一种类型换成另一种类型。所以需要急切实现的一个函数就是，能把一个LambdaExpression的参数类型换成另一种类型，于是我实现了下面的方法：（其中，TSource为源类型，TResult为目标类型）

public static Expression<Func<TResult, bool>> Replace<TSource, TResult>( 
    this Expression<Func<TSource, bool>> predicate)
{
    ParameterConverter pc = new ParameterConverter(predicate);
    return (Expression<Func<TResult, bool>>)pc.Replace(typeof(TResult));
}

    在开始写这段代码之前，我的表达式目录树知识几乎为0；于是又开始翻MSDN，找到了这里：……最终在MSDN的帮助下，我终于把它给实现出来了，完成后我不禁沾沾自喜(虽然只有几十行代码，可行代码不到十来行，剩下的是从MSDN中的ExpressionVisitor盗版的，但也耗了我整整一个半天)……

    古人云：乐极生悲。看来这句话还是有道理的。庆幸之后，接着我又坠入了万丈深渊，因为我不知道怎么调用这个方法！在这个方法外部，我们的query是IQueryable<匿名类型>，在IQueryable<匿名类型>.Where()方法中，尝试调用这个Replace方法的时候，我不知道该传什么类型参数给TResult。我又白干了……

 

    有时候，看起来只有一步之遥，但其实天各一方……

                                      ------------------我是可耻的分割线(happyhippy.cnblogs.com)--------------------

    有时候，看起来貌似遥不可及，但其实近在咫尺……

 

    前面提到：在L2S中，查询被表示为一个表达式目录树(Expression Tree，表示的是数据，不是代码)。我既然可以向上面这样修改Expression<Func<TSource, bool>>，那我应该也可以修改这个这个LINQ查询，而且Dynamic LINQ也正是在修改LINQ查询啊。

    看了下Dynamic LINQ中对Where的扩展，才知道IQueryable公布了其Provider属性：IQueryable.Provider，我们可可以直接调用Provider.CreateQuery来对原有的query进行扩充：

Expression<Func<Products, bool>> predicate = t => t.ProductName.Contains("che") && t.UnitPrice >= 22;
IQueryable query = from P in context.Products
                   join S in context.Suppliers
                   on P.SupplierID equals S.SupplierID
                   select new
                   {
                       P.ProductName,
                       P.UnitPrice,
                       P.QuantityPerUnit,
                       S.CompanyName
                   };
query = query.Provider.CreateQuery(
    Expression.Call(
        typeof(Queryable), "Where",
        new Type[] { query.ElementType }, 
        query.Expression, predicate.Replace<Products>(query.ElementType)));

    前面，我无法完成将TSource(Products)强制转换成匿名类型；但这里，通过构造Expression，来将类型弱化，最终将通过Expression的编译和执行功能，来实现这种转换。

    当然，每次这样写的话，我也觉得麻烦；于是，就有了下面的对IQueryable的扩展：

public static IQueryable DynamicWhere<T>(this IQueryable query, Expression<Func<T, bool>> predicate)
{
    if (predicate == null)
        return query;
 
    return query.Provider.CreateQuery(
        Expression.Call(
            typeof(Queryable), "Where",
            new Type[] { query.ElementType },
            query.Expression, predicate.Replace<T>(query.ElementType)));
}
 
//然后就可以这样用了：
public List<ProductExt> TestDynamicQuery3()
{
    using (NorthWindDataContext context = new NorthWindDataContext())
    {
        IQueryable query = from P in context.Products
                           join S in context.Suppliers
                            on P.SupplierID equals S.SupplierID
                           select new
                           {
                               P.ProductName,
                               P.UnitPrice,
                               P.QuantityPerUnit,
                               S.CompanyName,
                               S.Address
                           };
        query = query.DynamicWhere((Products p) => p.ProductName.Contains("che"))
            .DynamicWhere((Suppliers s) => s.Address == "P.O. Box 78934") 
            //.DynamicWhere((ProductExt p) => p.CompanyName == p.ProductName) //BinaryExpression右边不能有对参数的引用
            .DynamicWhere((Products p) => p.UnitPrice >= 5 * 4 + 2);
 
        return query.ConvertTo<ProductExt>();
    }
}

    由于Where<TSource>(this IQueryable<TSource> source, Expression<Func<TSource, bool>> predicate)已经被可耻地占去了，所以这里我定义了一个自己的方法名：DynamicWhere。

                                      ------------------又可耻了一次的分割线(happyhippy.cnblogs.com)--------------------

    最后，来说说这种方法的不足之处：
    (1). 由于我们在Expression<Func<TSource, bool>> predicate时，使用的源类型TSource与query中元素类型(匿名类型)之间的属性集可能存在不同，因此这里的Expression中，只能使用匿名类型中已经声明的属性，使用不属于该匿名类型的属性时，编译时不会抱错，但运行时会出错。例如，我还补充传入了一个根据供应商所在城市的过滤条件：.DynamicWhere((Suppliers s) => s.City== "London")，运行时就挂了……这就又遇到上一节中同样的问题：UI层怎么知道属性可用，哪些属性被阉割了呢？这又是一个问题，暂时只能说：源代码前没有秘密。
    (2). BinaryExpression中的右侧表达式不能包括对参数的应用。譬如上面代码中注释掉的一行，引用了参数p，执行会报错；这是因为在处理类型参数转换时，我对BinaryExpressio中的右侧表达式和CallExpression中的参数表达式进行了运算，转得到常量表达式。应该还有更好的思路，判断这些Expresion是否引用了参数，如果引用了参数，则不进行运算，如果没有引用参数，则进行运算。但是我还没有考虑出来该怎么来判断……于是就成了这个样子。不过对于动态查询来说，一般情况下应该够用了，以后想到更好的思路再加进去。

 

5. 如何进行逻辑复用

    为了将思路描述清楚，前面我只介绍了如何进行动态查询，而刻意避开了一个问题，就是如何进行逻辑复用。问题要分解开来，然后再逐个击破~

5.1 UI与业务逻辑层位于同一地址空间(同一个应用程序域)

    既然位于同一地址空间，那就可以在UI层创建Expression<Func<TSource, bool>> predicate，然后传入业务逻辑层：

public List<ProductExt> TestDynamicQuery(Expression<Func<ProductExt, bool>> predicate)
{
    using (NorthWindDataContext context = new NorthWindDataContext())
    {
        IQueryable query = from P in context.Products
                           join S in context.Suppliers
                            on P.SupplierID equals S.SupplierID
                           select new
                           {
                               P.ProductName,
                               P.UnitPrice,

相关推荐

电脑软件

热门排行

今日推荐

热门手游