WCF 数据服务分页行为
在我的示例项目中，我将实体页面大小设置为 20。然后我有一个实体集，其结果计数可被页面大小整除。例如，类别集有 100 个项目。当我转到：
http://localhost/Sample.svc/Categories?$skiptoken=80
我有第 81 到 100 个类别，并且该页面有“下一个”链接时，
http://localhost/Sample.svc/Categories?$skiptoken=100
我尝试转到该页面，但它什么也没返回。 对此有何解释？
In my sample project, I set the entity page size to 20. Then I have an entity set with result count which is divisible to the page size. For example, the Categories set which has 100 items. When I go to:
http://localhost/Sample.svc/Categories?$skiptoken=80
I got 81st to 100th categories and the page has the "next" link
http://localhost/Sample.svc/Categories?$skiptoken=100
I tried to go to that page and it returns nothing.
What's the explanation for that?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
分页仅获取下一个 PageSize 项目。如果发现的数量少于该数量，那么很明显没有更多的物品可返回，因此您不会获得下一个链接。如果查询返回请求的项目数，则运行时不会尝试确定这是否是最后一页，它只是返回下一个链接。此类链接可能不会返回任何结果。
事实上，下一个链接不一定会返回任何结果，但只要响应包含另一个下一个链接，就可能有更多结果。标准内置分页将返回预定义大小的页面（最后一页除外），但服务可以自由使用任何其他类型的分页，这可能会为每个页面（包括空页面）返回不同的大小。
直接回答你的问题“为什么最后一页是空的？”：
运行时不会“向前看”，因此它无法判断给定页面是否是最后一页，除非它获得的结果数量少于预期的结果。展望未来，成本高昂（要求超出必要的范围），而且可能是错误的（如果额外的结果导致错误怎么办……）。
The paging simply takes the next PageSize items. If it finds less than that, then it's clear there are no more items to return so you don't get the next link. If the query returns the requested number of items, the runtime doesn't try to figure out if this is the last page or not, it simply returns a next link. It might happen that such a link will return no results.
In fact the next link is not bound to return any results, but as long as the response constains another next link, there are potentially more results. The standard built in paging will return pages of the predefined size (except for the last one), but services are free to use any other kind of paging which might return different sizes for each page (including empty pages).
To directly answer your question "Why is the last page empty?":
The runtime doesn't "look ahead" so it can't tell if a given page is the last one except for when it gets less than the expected number of results. Looking ahead would be both costly (asking for more than necessary) and potentially wrong (what if the extra result causes an error...).