使用 TSQL、MVC3 和 SubSonic 进行分页？
我正在尝试确定执行分页的最佳方法。
我有两种使用 SubSonic 抓取数据的选项：
1) itemDatumCollection.LoadAndCloseReader(sp.GetReader()); 或者 2) itemsDataSet = sp.GetDataSet();
对于两者，我都访问相同的存储过程。有没有一种简单的方法使用 LoadAndCloasReader() 进行分页？
我可以通过客户端上的 GetDataSet 加载所有数据 - 比如说 4000 行，但似乎没有必要，并且当我使用 LoadAndCloseReader() 时，这个数据量超出了我的 WCF 绑定参数（我认为设置得很好），因为它返回一个复杂的对象：
maxBufferSize="20000000" maxBufferPoolSize="524288" maxReceivedMessageSize="20000000"
所以我猜有几件事：
1）GetDataSet() 返回数据是否更快 - 我不需要复杂的集合对象（编码时它很好）？
2) 如何使用 TSQL 存储过程执行分页？
谢谢。
I'm trying to determine the best approach for performing paging.
I have two options of grabbing data using SubSonic:
1) itemDatumCollection.LoadAndCloseReader(sp.GetReader());
or
2) itemsDataSet = sp.GetDataSet();
With both I am accessing the same stored procedure. Is there a simple way of paging with LoadAndCloasReader()?
I could load all the data through GetDataSet on the client - say 4000 rows, but seems unnecessary, and this amount of data exceeds my WCF binding parameters (which I think are set pretty good) when I use LoadAndCloseReader() as it returns a complex object:
maxBufferSize="20000000" maxBufferPoolSize="524288" maxReceivedMessageSize="20000000"
So a couple of things I guess:
1) Is GetDataSet() faster at returning data - I don't need the complex collection object (it's just nice when coding)?
2) How can I perform paging using my TSQL sproc?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我采用了 MVVM 中使用较多的方法，而不是 MVC。我预先加载了所有数据，然后允许用户使用 jQuery 分页控件对其进行分页，从而最大限度地减少对数据库的返回调用。初始响应需要更长的时间（但仅限于 100 条记录），但为用户提供了闪电般快速的寻呼。
我使用了 简单分页器 jQuery 插件< /a>.
I went with an approach used more in MVVM, rather than MVC. I loaded all the data up front, then allowed the user to page through it using a jQuery paging control, there-by minimizing return calls to the database. The initial response takes a bit longer (but is limited to 100 records), but provides the user with lightening-fast paging.
I used the Simple Pager jQuery plugin.