顶 加上记号 谢谢

嘿 不错 好东西 正好需要 做个记号 谢谢

@腾飞刘 EasyUI官方说是尽量减少json中的键值，把不显示的键值去掉，减少json数组的体积会减少treegrid的解析时间，这样会提高不少性能，希望对你有用 其他办法就是底层或许可以利用缓存，不需要每次都查询数据库然后拼装 目前只是想到这些，不知道对你有没有帮助

你好，我按照你的DEmo做了，很成功。在没有分页的情况下，数据达到200条的时候，就需要等50秒，（后台获取数据的方法性能损耗很小）请问我如何提高性能？谢谢，我的qq 350020527 。在线等。。。

@曾俊杰 你的json格式有问题，根节点不能有_parentId

@曾俊杰 你的json格式不对，如果是根节点json里没有_parentId

能提供给我一份例子么 能给我一份例子么，我照着你的文档做了个treegrid 可是不能出来 {"total":9,"rows":[{"Identifier":"1","Area_Name":"数据融合系统","_parentId":"-1"},{"Identifier":"2","Area_Name":"统计数据","_parentId":"1"},{"Identifier":"3","Area_Name":"全业务套餐发展量","_parentId":"2"},{"Identifier":"4","Area_Name":"状态统计查询","_parentId":"2"},{"Identifier":"5","Area_Name":"装拆机统计查询","_parentId":"2"},{"Identifier":"6","Area_Name":"产品（分客户群）装拆机统计","_parentId":"2"},{"Identifier":"7","Area_Name":"清单","_parentId":"1"},{"Identifier":"8","Area_Name":"子项一","_parentId":"7"},{"Identifier":"9","Area_Name":"子项二","_parentId":"7"}]}

能给我一份例子么，我照着你的文档做了个treegrid 可是不能出来 {"total":9,"rows":[{"Identifier":"1","Area_Name":"数据融合系统","_parentId":"-1"},{"Identifier":"2","Area_Name":"统计数据","_parentId":"1"},{"Identifier":"3","Area_Name":"全业务套餐发展量","_parentId":"2"},{"Identifier":"4","Area_Name":"状态统计查询","_parentId":"2"},{"Identifier":"5","Area_Name":"装拆机统计查询","_parentId":"2"},{"Identifier":"6","Area_Name":"产品（分客户群）装拆机统计","_parentId":"2"},{"Identifier":"7","Area_Name":"清单","_parentId":"1"},{"Identifier":"8","Area_Name":"子项一","_parentId":"7"},{"Identifier":"9","Area_Name":"子项二","_parentId":"7"}]}

lihai

讲师现在微软内部工作 有多年.NET开发经验 让你体验不一样的授课风格 零基础的同学们，火速报名啦 经过去年第一期的培训，发现效果显著，收益学生近百人 不少同学都从零基础的状态迅速入门 不要你有行业背景，不要你写过一行代码，只要有一颗努力上进的心 有意参与者加群：175459066（疯狂C杀特训营） 终身免费，只要你有心学，就一定可以有收获 另诚聘有分享意愿的，同样无私的同行任讲师

测试暂时还没做过．目前用网上流行的二分法存储过程

楼主的方法效率没什么高，代码也不简洁。

ROW_NUMBER我也偿试过，效率不高！
如果楼上的各位觉得效率高的肯定是
1 数据不多100W以下
2 没有使用多条件，多排序或者较复杂的逻辑

注：以上都是指在有索引的条件下进行

我在2005一出时就立即使用了这一特性，刚开始时我使用100多W数据只是很简单的就使用ROW_NUMBER来分页，结果效果很可观，返回时间基本上在300毫秒以下，前几十页更快，基本上是10几的
后来我将它使用在项目中，结果发现效率非常的差。。。排除了索引优化。
结果还是慢。。。

后来我得出一个结论：没有绝对好的分页程序、或者方法，只有好好的分解需求，再作出相应比较好的解决方案，这样子才有可能提高程序效率或者分页速度(如没必要显示上百W页码...)。。。

是吗？row_number我没测试过，修改一下试试，谢谢zbmwt

呵呵，楼主我觉得那个分页好麻烦啊

row_number的效率确实是很好。我测试过1千万的数据，感觉效率很好，比select top n的方法还快一点点。另外，关键是写起来语法简便多了。呵呵。

２００５有个新方法提高分页效率啊
ROW_NUMBER()你应该知道的吧．
虽然我没完全看你写的储存过程分页，但是我感觉ＲＯＷ＿ＮＵＭＢＥＲ（）效率很高！

Test test = new Test();
//属性赋值
test.Identifier = 1;
test.TestName = "Test";
//创建业务逻辑对象
Business business = new Business();
//注册委托方法
test.AddSaveMethod(business.Save<Test>);
//保存数据
test.Save();

保存一个实体对象太麻烦了，你要想办法这样实现，你那个业务对象在这里是多余的，这些对象要放在save方法里面去做，用泛型委托可以实现
Test test = new Test();
//属性赋值
test.Identifier = 1;
test.TestName = "Test";
//保存数据
test.Save();
做到这么简单才算OK，你得把你的那些代码移到save方法里面去

我以前实现个这个，我给看看我的代码片段：
Photo a = new Photo();
a.id = 12;
a.subject = "asdfasdf";
a.save();
这个代码会把图片的对象保存到我的对应的数据库的photo的表中去，所有代码的实现都在save这个方法里面。

每次+-耗资源，可以考虑缓存
而且每次都没lock。。不安全

--引用--------------------------------------------------
GUO Xingwang: ......
以后想怎么做呢，其实我觉得实体类中的贫血实体类的作用就是传送数据，要不就是充血实体类！你这样做多少会有些职责不清，这是我的观点！
--------------------------------------------------------
同意。持久化功能，还是归dao，也就是当做一个服务使用。业务归充血实体，持久化归dao。我个人认为，不是把持久化方法和实体对象整合一起就叫做充血模式。Hibernate in Action 第二版也讨论过类似的问题，最后作者的结论是持久化和Domainobject必须分开。另外Identity有set的方法，是不是有点违背封装原则。