首先我們來看看日常比較典型的一種查詢Form

這個場景很簡單：就是根據(jù)客戶名、訂單日期、負責人來作篩選條件，然后找出符合要求的訂單。

在那遙遠的時代，可能避免不了要寫這樣的簡單接口：

public interface IOrderService {IList<Order> Search(string customer, DateTime dateFrom, DateTime dateTo, int employeeID); }

具體愛怎么實現(xiàn)就怎么實現(xiàn)啦，存儲過程，ORM框架。這里假定是用了孩童時代就開始有的存儲過程吧：

Create Procedure usp_SearchOrder @Customer nVarchar(20), @DateFrom DateTime, @DateTo DateTime, @EmployeeID Int AS /*... 以下省去幾百行SQL語句*/

接著寫一個類OrderService實現(xiàn)IOrderService， 調(diào)用以上存儲過程，洋洋灑灑的寫上幾句代碼就可以“安枕睡覺”了。但是，噩夢就從此開始了。

客戶的需求是不斷變化的。過了一段時間，設(shè)計這個接口的工程師就先被夸贊一番，然后說客戶提出需要加多“一個”篩選條件。工程師可能也想過這一點，加一個篩選條件“不外乎“給接口加個參數(shù)，存儲過程加個參數(shù)，where那里加個條件，……苦力活一堆。

客戶的篩選條件是這樣：既然訂單里有“國家”字段，就想根據(jù)國家來篩選條件，并且國家可多選，如下圖：

工程師看到圖可能就倒下了……

以上可以當作笑話看看，不過話說回來，沒有一個通用的查詢框架，單靠這樣的接口

public interface IOrderService {IList<Order> Search(string customer, DateTime dateFrom, DateTime dateTo, int employeeID); }

是根本不能適應需求變化。

在沒有Linq 的時代， SQL“ 強人”就試圖通過拼接字符串的方法來結(jié)束存儲過程帶來的痛苦，

IList<Order> Search(string sqlQurey);

結(jié)果進入另一個被“SQL注入”的時代（注：我大學時也有一段時間玩過“SQL注入”，不亦樂乎，現(xiàn)在基本上很少找到能夠簡單注入的網(wǎng)站了，有磨難就有前進的動力嘛）。

來到Linq To SQL 的時代 （不得不贊嘆Linq把查詢發(fā)揮到淋漓盡致）， 某些朋友就能輕易地揮灑Linq表達式來解決查詢問題：

IList<Order> Search(Expression<Func<Order, bool>> expression);

查詢語句：

Expression<Func<Order, bool>> expression = c =>c.Customer.ContactName.Contains(txtCustomer.Text) &&c.OrderDate >= DateTime.Parse(txtDateFrom.Text) && c.OrderDate <= DateTime.Parse(txtDateTo.Text) &&c.EmployeeID == int.Parse(ddlEmployee.SelectedValue);

然后再一次 “安枕睡覺”。一覺醒來還是不行。

客戶又來新需求：負責人的下拉框加個“ALL”的選項，如果選了“ALL”就搜索所有的負責人相關(guān)的Order。

工程師刷刷幾下，又加if else，又加 and 來拼裝expression；接著又來新需求，…… 最后expression臃腫無比 (當然這個故事是有點夸張)。

為什么用上“先進”的工具還是會倒在慘不忍睹的代碼海洋里呢？因為Microsoft提供給我們的只是“魚竿”。這種魚竿不管在小河還是大海都能釣到東西，而且不管你釣的是鯊魚還是鯨魚，也保證魚竿不會斷。但是有些人能釣到大魚，有些則釣到一雙拖鞋。因為關(guān)鍵的魚餌沒用上。也就是說，Microsoft給了我們強大的Linq 表達式，可不是叫我們隨便到表現(xiàn)層一放就了事，封裝才是硬道理。

于是，千呼萬喚始出來，猶抱 QueryBuilder 半遮臉：

var queryBuilder = QueryBuilder.Create<Order>().Like(c => c.Customer.ContactName, txtCustomer.Text).Between(c => c.OrderDate, DateTime.Parse(txtDateFrom.Text), DateTime.Parse(txtDateTo.Text)).Equals(c => c.EmployeeID, int.Parse(ddlEmployee.SelectedValue)).In(c => c.ShipCountry, selectedCountries );

這樣代碼就清爽很多了，邏輯也特別清晰，即使不懂Linq 表達式的人也能明白這些語句是干什么的，因為它的語義基本上跟SQL一樣：

WHERE ([t1].[ContactName] LIKE '%A%') AND ? (([t0].[OrderDate]) >= '1/1/1990 12:00:00 AM') AND (([t0].[OrderDate]) <= '9/25/2009 11:59:59 PM') AND ? (([t0].[EmployeeID]) = 1) AND ? ([t0].[ShipCountry] IN ('Finland', 'USA', 'UK'))

?

對于使用這個QueryBuilder的人來說，他覺得很爽，因為他明白釣什么魚用什么魚餌了，模糊查詢用Like，范圍用Between，……

對于編寫這個QueryBuilder的人來說，也覺得很爽，因為他本身熱愛寫通用型的代碼，就像博客園的老趙那樣。

?

看到使用方式，聰明人自然就已經(jīng)想到大概的實現(xiàn)方式。就像廚師吃過別人煮的菜，自然心中也略知是怎么煮的。

實現(xiàn)方式并不難，這里簡單說明一下：

QueryBuilder.Create<Order>() 返回的是IQueryBuilder<T> 接口，而IQueryBuilder<T> 接口只有一個 Expression 屬性：

/// <summary> /// 動態(tài)查詢條件創(chuàng)建者 /// </summary> /// <typeparam name="T"></typeparam> public interface IQueryBuilder<T> {Expression<Func<T, bool>> Expression { get; set; } }

于是 Like， Between， Equals， In就可以根據(jù)這個Expression 來無限擴展了。

以下是實現(xiàn)Like的擴展方法：

/// <summary> /// 建立 Like ( 模糊 ) 查詢條件 /// </summary> /// <typeparam name="T">實體</typeparam> /// <param name="q">動態(tài)查詢條件創(chuàng)建者</param> /// <param name="property">屬性</param> /// <param name="value">查詢值</param> /// <returns></returns> public static IQueryBuilder<T> Like<T>(this IQueryBuilder<T> q, Expression<Func<T, string>> property, string value) {value = value.Trim();if (!string.IsNullOrEmpty(value)){var parameter = property.GetParameters();var constant = Expression.Constant("%" + value + "%");MethodCallExpression methodExp = Expression.Call(null, typeof(SqlMethods).GetMethod("Like",new Type[] { typeof(string), typeof(string) }), property.Body, constant);Expression<Func<T, bool>> lambda = Expression.Lambda<Func<T, bool>>(methodExp, parameter);q.Expression = q.Expression.And(lambda);}return q; }

每個方法都是對Expression進行修改，然后返回修改后的Expression，以此實現(xiàn)鏈式編程。

稍微有點意思的就是 In的擴展方法（這個害我費了不少時間，前前后后可能4個小時）：

/// <summary> /// 建立 In 查詢條件 /// </summary> /// <typeparam name="T">實體</typeparam> /// <param name="q">動態(tài)查詢條件創(chuàng)建者</param> /// <param name="property">屬性</param> /// <param name="valuse">查詢值</param> /// <returns></returns> public static IQueryBuilder<T> In<T,P>(this IQueryBuilder<T> q, Expression<Func<T, P>> property, params P[] values) {if (values != null && values.Length > 0){var parameter = property.GetParameters();var constant = Expression.Constant(values);Type type = typeof(P);Expression nonNullProperty = property.Body;//如果是Nullable<X>類型，則轉(zhuǎn)化成X類型if (IsNullableType(type)){type = GetNonNullableType(type);nonNullProperty = Expression.Convert(property.Body, type);}Expression<Func<P[], P, bool>> InExpression = (list, el) => list.Contains(el);var methodExp = InExpression;var invoke = Expression.Invoke(methodExp, constant, property.Body);Expression<Func<T, bool>> lambda = Expression.Lambda<Func<T, bool>>(invoke, parameter);q.Expression = q.Expression.And(lambda);}return q; }

?

如果有興趣的朋友可以在文章末下載源代碼，看看其他兩個擴展方法。

嗯，似乎又是時候退場了。什么？你說只有Like， Between， Equals， In不夠用？哦，可以自己擴展IQueryBuilder，自己動手豐衣足食嘛。

我后來又為另外一個Project做了一個“奇怪”的擴展：

譬如，我們知道打印設(shè)置里可以直接寫頁數(shù)號碼來篩選要打印哪幾頁——1，4，9 或者 1-8 這樣的方式。

于是引發(fā)這樣的需求：

左圖查詢Bruce和Jeffz的訂單；右圖查詢B直到Z的客戶訂單。

還美其名曰：Fuzzy ，意即：模糊不清的 （點這里看 Fuzzy詳細意思）

總結(jié)：

其實這篇文章已經(jīng)醞釀好久了，近期工作收獲很多編程技巧。一個Project下來了，又是時候總結(jié)一下，希望有空能夠繼續(xù)與大家分享。

源代碼下載：CoolCode.Linq.rar

建議參考新一篇《QueryBuilder ： 打造優(yōu)雅的Linq To SQL動態(tài)查詢(支持EF、.Net4)》

參考：

http://www.cnblogs.com/neuhawk/archive/2007/07/07/809585.html

http://www.cnblogs.com/billgan/archive/2009/01/08/1371809.html

http://www.cnblogs.com/lyj/archive/2008/03/25/1122157.html

http://www.cnblogs.com/126/archive/2007/09/09/887723.html

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術(shù)人生

總結(jié)

以上是生活随笔為你收集整理的QueryBuilder ： 打造优雅的Linq To SQL动态查询的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。