用于可能的大型有效负载的 WCF 分页答案

【问题标题】：WCF paging for posible large payloads用于可能的大型有效负载的 WCF 分页
【发布时间】：2016-11-24 19:02:46
【问题描述】：

当前，当操作返回对象集合时，我们的 WCF 服务都会处理某种类型的分页。但是我们发现，在某些情况下，某些操作可能会返回一组不那么简单的对象，这些对象最终会产生超过 64K 阈值的响应，所有最佳实践文档都要求我们尝试维护以优化底层 tcp 通道，一切正常.

例如，我们的服务可以返回在影院放映的电影列表，客户可以询问每部电影在某个时间段内的每日定价、放映时间和座位可用性；那就是“给我正在放映的电影列表和未来 30 天的每日信息”。问题是我们不能简单地限制客户可以要求的天数。所以即使我们限制在单个呼叫中返回的电影数量，客户请求信息超过 30 天也会产生很大的响应我们尽量避免。

流式绑定是不可能的，因为我们所有的服务都是单向的，使用某种类型的队列作为通道。我们可以研究什么样的合同设计来管理这些类型结果的大小？当然，我们也希望避免过于复杂的合同，因为合同能够分页响应的各个方面，因为这对任何人都没有好处。

【问题讨论】：

不知道你有没有design problem。为什么要在同一个请求中返回电影未来 30 天的每日信息？获取电影列表然后仅在用户选择某些内容时获取每日信息不是更好吗？这样您就不会获取用户可能不会使用的数据
@User52784246，客户端可以在响应中包含或排除每日信息，但我们的一些应用程序需要包含它以减少在单个 UI 操作中访问服务器的次数。对于这些应用来说，这是技术上的必需品。
减少number of trips 对于少量数据是一个很好的策略，但对于大数据响应，例如在您的情况下是多次旅行的开销 i> 与接收单个大响应的时间相比，前者微不足道

标签： c# wcf paging

【解决方案1】：

在某个点之外，你必须做出选择。您不能既发送大量数据又保持在 64k 以下...

可能还有其他选择和方法，但这里有一些示例：

在请求本身中添加分页选项并向用户说明他必须使用它。
如果需要，在答案中强制分页（即使用户在问题中不需要）并将其指定给用户（返回的项目数/剩余项目数）。为了使其更易于使用，您可以创建一种有状态的服务，其中存在特定令牌，从而使用户能够直接询问下一个结果集。这样，他不必明确处理页面大小/跳过，只需询问“现在将与此令牌对应的下一个结果集发送给我”，他就可以获得更流畅的内容。
找到简化合同的方法：删除无用的字段，简明扼要地表达......
二进制压缩数据，如果不是
更改绑定（您似乎已经考虑过了）

【讨论】：

感谢@Richard 的提示。我可以使用令牌分页找到已知的 API，但我会很感激实现参考或任何讨论该模式的内容。
提示：搜索“继续令牌”、“跳过令牌”或“服务器驱动的分页”。这是一个 Microsoft 示例，它适用于 OData，但它可以推动您实现它：blogs.msdn.com/b/odatateam/archive/2010/02/02/…。也许还有更多“有限”资源可用于在肥皂绑定中实现它。
你也可以看看stackoverflow.com/questions/8503562/…

【解决方案2】：

我们可以研究什么样的合同设计来管理这些类型结果的大小？

与其请求天数（接下来的 30 天），不如请求一个具体的时间段（在“2014 年 10 月 4 日”和“2014 年 10 月 14 日”之间） ）并验证此具体期限的长度是否短于某个限制（例如，30 天）。周期长度限制是根据 64k 传输阈值 或其他一些技术因素选择的。

将长周期分成更小的周期（如有必要）通常没有问题，从客户端应用程序执行 2-3 个请求并连接结果。

【讨论】：