动态多条件查询分页以及排序(一)--MVC与Entity Framework版url分页版

博客园_

您正在查看的源包含频繁更新的内容。订阅源后，该源会添加到“常见源列表”中。该源的更新信息会自动下载到计算机，通过 Internet Explorer 及其他程序可以查看这些信息。进一步了解源。

订阅该源

动态多条件查询分页以及排序(一)--MVC与Entity Framework版url分页版

2012年12月4日，8:46:00 | wlf

一.前言

多条件查询分页以及排序每个系统里都会有这个的代码做好这块可以大大提高开发效率所以博主分享下自己的6个版本的多条件查询分页以及排序

二.目前状况

不论是 还是EF 在做多条件搜索时都有这类似的代码

这样有几个不好的地方

1.当增加查询条件,需要改代码,对应去写相应的代码。

2.对多表查询以及or的支持不是很好。而我们很常见的需求不可能是一个表的查询

3. 这样写表示层直接出现了SQL语句或者 linq 的拉姆达表达式这是很不好的表示层不应该知道数据访问技术

4.有的时候我们的业务逻辑层接口是这样的 IList<***> seach(string name,string age,string classname,int pageindex,int pagesize,string oderby)

这个时候多一个查询条件对应的还要去修改业务逻辑层 EF由于传递的是表达式树,则更是苦不堪言.

三.我们接下来应该实现的目标

1.当增加条件时不需要修改代码只需要在view上增加相应的查询框即可

2.我们的多条件查询应该做到无关表示层技术(是否是MVC或webform)

3.应该支持多表查询以及OR的操作

4.应该支持更多的查询 like in 不等于等操作

5.关于分页不应该与数据访问耦合在一起个人感觉分页只需要知道总条数

以及当前页数和每页多少条然后生成分页代码即可不应该与EF等耦合到一起分页应该是独立出来可控制的

6.客户可以自己添加搜索条件这是个强大的功能想怎么查客户自己添加即可

7. 统一查询接口做到有条件增加不修改代码

8.分页应该支持 url重写或者 mvc路由不应该生成的连接只是?pageindex=值这种的

四.我实现的几个多条件查询分页版本以适应各种需求(每篇会写一个版本的实现以及代码的提供,有好

意见的欢迎留言)

1.url get提交版实现URL分页多条件查询以及排序的好处是我们可以把当前的搜索条件当前页数排序等都在url上显示可以方便的发给好友以及后退等浏览器操作(个人给dudu老大建议,博客园应该做成这种的)

2.post 提交版本的搜索条件较大不适合用url的

3.ajax+mvc版本的 (关于AJAX实现我认为有两种 1.服务端实现好内容的拼接,传输给客户端 2直接传递json给客户端客户端来做拼接)

这个版本会实现服务端拼接内容好处是服务端做拼接简单能做更多的事情维护服务端代码方便尤其是强大的Razor

4.ajax+webapi+Knockoutjs 版本

这个版本我实现的是服务端只是传递 json 这样服务端效率很高喜欢这样开发方式的朋友就是前端拼接字符是很不好的代码会显得很乱这个时候前端就需要一个模版引擎我用的是 jquery-temp 配合强大的Knockoutjs

5.动态增加查询条件版

这个版本我实现的是客户可以自己添加查询条件查询条件是动态的

6.移植到webform版

7.EF应该得到表达式树让EF自己生成SQL语句这样方便扩展实现其他方法

五.url get提交版开始

废话了那么多今天就写下url get版的多条件查询以及分页排序

先上个丑陋界面的截图界面虽丑但是功能齐全查询分页排序齐全

看下控制器的代码

我们这里没有各种条件判断判断哪个为空使用哪个排序的判断我们的业务逻辑层接口没有接受表达式树的参数与数据访问层不是耦合的而是使用了Querymodel对象来抽象所有查询条件

这样这个对象可以翻译成 EF的表达式树也可以翻译成SQL语句所以我们的表示层MVC 不用非要使用EF的的底层

而我们的分页只需要知道当前页数总数据以及每页大小去自动生成分页

关于分页很多人喜欢把这个扩展htmlhelper 做成 html.pager 这种做法这样很多表示层的展示都会耦合到这个里面举个例子,比如把分页的布局从table 变成 ul 这样的这是纯表示层的

本应该修改 view 现在却要去改htmlhelper 而且你的分页代码越强大则htmlhelper 里的内容越多修改起来越不容易所以我的意见是做分页的最好使用html.Partial 然后把分页的逻辑写到

部分页里这样就实现了分页只关注分页与其他的一切都没有关系我们要做的就是构建 Pager类然后传递给模版即可例如

这个版本要注意的就是分页后要保存查询条件

六.url get提交版实现分析

1.先来说下多条件查询吧

我们要做的是把各个条件构建成QueryModel 而如何构建则是关键我们想下获得mvc提交的内容的是根据name 所以我们可以固定一个name的格式如

ID(like操作)：

这样我们可以通过正则获取想要信息的部分然后在模型绑定构建出QueryModel对象然后再把这个对象翻译成SQL语句或者表达式树就可以用于ado 或者 EF操作了

顺便重点说下这个思路园子里的重典早都实现了而且实现的很好大家可以去他的博客看下以后的各个版本的分页都会用这个表达式树构建为基础这是他文章的链接重典老哥的实现

(ps:这周刚刚见过他本人,聊得甚欢,开心.希望以后还可以多聚聚)

不过重典老哥的表达式树构建我改成自己的实现了整体思路还是一样的自恋的说下 ~ 我的可读性更高些哈哈因为重典已经描述的很详细了具体可以看我的代码和他的文章

当然我们得到通过QueryModel 得到的表达式树通过扩展方法直接调用Where方法即可让我们看下我们的EF的业务逻辑层

public class StudentService:IStudentService

{

///

///按条件搜索

///

///搜索条件

///当前页数(索引从1开始)

///每页显示条数

///总条数

///排序字段

///是否升序

///