我正在查看一些代码，我们在从 WCF Web 服务返回数据时遇到了一些问题。目前，该服务制作一个对象列表，将它们序列化（作为记录的 JSON）并返回整个序列化列表。显然，当有很多数据用户遇到配额限制问题时。
我正在考虑更改它，以便服务一次返回一个项目，这将在循环中发送一堆请求，一次将一个对象添加到列表中，直到完成。
显然，在场景一中，我们向服务发出了一个请求，该请求有可能返回大量数据并超出配额。在另一种情况下，我们从未达到配额，但请求应用程序将在单独的请求流中一个接一个地请求数据项。
为了说明这一点，我们有一个包含各种项目类型的项目列表，并且这些类型有不同的价格点。该应用程序可能想要聚合多个项目、想要该项目的客户、客户要求的项目类型和价格，他们可能是 70 个项目，每个客户平均要求 2 种产品类型1个价格。
在极端情况下取平均值，这可能会在一个完整的作业中产生 7000 个单独的（非常小的）数据请求。那是问题吗？可以稍微打包一下，以便可以捆绑请求的客户类型和价格，但一次仍然可能有几千个请求。
使用单个巨大的数据流会更好吗？还是几千个更小的？