动态多条件查询分页以及排序MVC与EntityFramework版url分页版.doc

因为此设置被禁用，所订阅的源没有被自动更新。 打开自动源更新 您已成功订阅此源! 可以在 Internet Explorer 及使用“常见源列表”的其他程序中查看更新内容。 查看我的源 您已成功订阅此源! 博客园_ 您正在查看的源包含频繁更新的内容。订阅源后，该源会添加到“常见源列表”中。该源的更新信息会自动下载到计算机，通过 Internet Explorer 及其他程序可以查看这些信息。进一步了解源。 订阅该源 博客园_ 年月日， 动态多条件查询分页以及排序(一)--MVC与Entity Framework版url分页版 年月日， 一.前言 二.目前状况 不论是 还是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 里的内容越多 修改起来越不容易 所以我的意见是 做分页