我正在查看一些代码，其中我们遇到了来自WCF Web服务的返回数据的一些问题。目前，该服务生成一个对象列表，将它们序列化（作为记录的JSON）并返回整个序列化列表。很明显，当有很多数据用户遇到配额限制问题时。
我正在考虑更改它，以便服务一次返回一个项目，该项目会在循环中发送一堆请求，一次将一个对象添加到列表中，直到完成为止。
显然，在方案一中，我们向服务发出一个请求，该请求有可能返回大量数据并且会违反配额。在另一个场景中，我们从未达到配额，但请求的应用程序将在单独请求流中的数据项之后请求数据项。
为了说明我们有一个项目列表，这些项目有各种各样的项目类型，这些类型有各种各样的价位。该应用可能希望聚合多个项目，需要该项目的客户，项目类型和客户要求的价格，以及它们可能是七十个项目，五到八十个客户，每个客户平均要求两种类型的产品每个1个价格。
在极端情况下取平均值可以在一个完整的作业中生成7000个单独（非常小）的数据请求。那是问题吗？可以将其打包一点，以便可以捆绑所请求的客户类型和价格，但这仍然可能同时有几千个请求。
我最好使用一个庞大的数据流吗？还是几千个小的？
答案 0 :(得分：2)
对于您的场景，您最好使用最佳大小的回报:)它有点取决于请求的开销。通常，来回网络服务的喋喋不休就越少。
滑稽的答案，所以这里有一个问题： 您可能最好使用某种寻呼系统，其中您的请求要求特定数量的项目，并且您的响应在结果中返回“n of m”。这样，您可以调整请求的数量和响应的大小，以便在您的情况下表现最佳。