当前，当操作返回对象集合时，我们的 WCF 服务都会处理某种类型的分页。然而，我们发现，在某些情况下，某些操作可能会返回一组不那么简单的对象，这些对象最终会产生超过 64K 阈值的响应，所有最佳实践文档都要求我们尝试维护该阈值，以优化一切正常运行的底层 tcp 通道。
例如，我们的服务可以返回剧院正在放映的电影列表，客户可以询问每部电影在一段时间内的每日定价、放映时间和座位可用性；那就是“给我正在放映的电影列表和未来 30 天的每日信息”。 问题是我们不能简单地限制客户可以请求的天数..因此，即使我们限制单次调用中返回的电影数量，请求 30 多天信息的客户也会产生大量响应，我们要尽可能避免。
流式绑定是不可能的，因为我们所有的服务都是以某种类型的队列作为通道的单向方式。 我们可以研究什么样的合同设计来管理这些类型结果的规模？当然，我们也希望避免过于复杂的合约，这些合约能够对响应的各个方面进行分页，因为这对任何人都没有好处。
超过某一点，你必须做出选择。您无法既发送大量数据又保持低于 64k...
可能还有其他选择和方法，但这里有一些例子：
在请求本身中添加分页选项并向用户解释他必须使用它。
如果需要，强制在答案中分页（即使用户在问题中不需要）并将其指定给用户（返回的项目数/剩余项目数）。 为了使其更易于使用，您可以创建一种有状态服务，并在答案中提供特定令牌，使用户能够直接询问下一个结果集。这样，他就不必显式处理页面大小/跳过，只需询问“现在向我发送与此标记相对应的下一个结果集”即可获得更流畅的结果。
找到一种简化合约的方法：删除无用的字段，简洁地表达事物......
如果不是则二进制压缩数据
更改绑定（你看起来已经考虑过了）
我们可以研究什么样的合约设计来管理这些类型结果的规模？
与其请求天数（接下来的 30 天），不如请求一个具体的时间段（“2014 年 10 月 4 日”和“2014 年 10 月 14 日”之间）并验证该具体时间是否有效期限短于某个限制（例如，30 天）。周期长度限制是根据64k 转账阈值或其他一些技术因素选择的。
将长周期分成更小的周期（如果需要），从客户端应用程序执行 2-3 个请求并连接结果通常没有问题。