WCF分页用于可靠的大型有效载荷

Question

当操作返回对象集合时，我们的WCF服务全部处理某种类型的分页。然而，我们发现在某些情况下，某些操作可以返回一组不那么微不足道的对象，这些对象最终会产生超过64K阈值的响应，所有最佳实践文档都会让我们尝试维护以优化底层tcp通道。 。

例如，我们的服务可以返回在影院中显示的电影列表，并且客户可以在一段时间内询问每部电影的每日定价，放映时间和可用性;那就是“给我显示正在播放的电影列表以及接下来30天的每日信息”。 问题是我们不能简单地限制客户可以要求的天数..因此，即使我们限制一次通话中返回的电影数量，请求信息超过30天的客户也会产生大的响应，我们要尽可能地避免。

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

Answer 1

超越某一点，你必须做出选择。你不能同时发送大量数据并保持低于64k ......

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

• 在请求中添加分页选项，并向用户解释他必须使用它。

• 如果需要，强制在答案中进行分页（即使用户在问题中不需要），并将其指定给用户（返回的项目数/剩余项目数）。 为了使其更易于使用，您可以使用响应中存在的特定令牌进行一种有状态服务，该特定令牌会向用户提供直接询问下一个结果集的能力。通过这种方式，他不必明确处理页面大小/跳过，只需询问“现在向我发送与此令牌对应的下一个结果集”，就可以获得更流畅的东西。

• 找到简化合同的方法：删除无用的字段，简洁地表达事物......

• 二进制压缩数据（如果不是

）

• 更改绑定（您似乎已经考虑过了）

Answer 2

  

我们可以通过什么样的合同设计来管理这些类型的结果？

而不是请求几天（接下来的30天），更合适的是要求具体期间（介于“Oct 4 '14”和“Oct 14 '14”之间）并验证此具体时段的长度是否短于某个限制（例如， 30天）。根据 64k传输阈值或其他一些技术因素选择周期长度限制。

将长时间段分解为较小的句点（如有必要）通常没有问题，从客户端应用程序执行2-3次请求并连接结果。