关于c#：通过Web服务返回大型结果

我目前正在使用Web服务，返回的结果可能会很大(> 5mb)。

这组数据如此之大且Web服务可以称为同步或异步是完全有效的，但是我想知道人们对以下内容的看法：

如果连接断开，则
整个结果集必须是
重新生成并再次发送。有没有
我可以做任何事情的任何方式
如果连接断开，则"恢复"
或重置？

发送这样大的结果集是否合适？在生成结果集并将其存储在服务器上，然后客户端可以下载少量结果集块并在其末尾重新组装该集的情况下，实现某种"分页"会更好吗？

---

我已经看到了分页，存储和检索以及大量推送的所有三种方法。

我认为您问题的解决方案在一定程度上取决于为什么结果集如此之大以及如何生成结果集。您的结果会随着时间的推移而增长吗？它们是否会一次全部计算出来然后再推送？是否要在收到它们后立即将其流回？

分页方法

以我的经验，当客户端需要快速访问类似于搜索结果页面中大小合适的结果集块时，使用分页方法是合适的。这里要考虑的是协议的整体闲谈，客户端页面请求之间的整个结果集的缓存和/或生成结果页面所需的处理时间。

存储和检索

当结果不是随机访问并且结果集的大小随查询处理而增长时，<存储和检索>非常有用。这里要考虑的问题是客户端的复杂性，是否可以为用户提供部分结果，或者是否需要在将任何内容返回给客户端之前计算所有结果(请考虑对来自分布式搜索引擎的结果进行排序)。

大规模推

几乎可以肯定，大规模推送方法是有缺陷的。即使客户端需要所有信息并且需要将其推送到一个整体的结果集中，我还是建议您采用WS-ReliableMessaging的方法(直接或通过您自己的简化版本)并对结果进行分块。通过此操作，您

确保碎片到达客户

您可以在收到客户收据后立即丢弃该块

可以在服务器和客户端上保留5MB的XML，DOM或任何内存(假设您不是以流方式处理结果)，从而减少内存消耗的可能问题。

不过，就像其他人所说的那样，请不要做任何事情，直到您知道结果集的大小，如何生成以及将整体性能作为实际问题为止。

---

对于结果集大小，没有针对5 Mb的硬性规定。超过400 Mb可能很难发送。

您将自动获得异步处理程序(因为您使用的是.net)

implement some sort of"paging" where
the resultset is generated and stored
on the server and the client can then
download chunks of the resultset in
smaller amounts and re-assemble the
set at their end

这已经在您身上发生了-称为tcp / ip ;-)重新实现可能会过大。

类似地-

entire resultset will have to be
regenerated and sent again

例如，如果它是MS-SQL，它将生成大多数结果集-则重新生成它将利用SQL Server中的某些隐式缓存，随后的生成将更快。

在某种程度上您可以不必担心这些问题，直到它们浮现为"真正的"问题为止-因为您使用的平台为您解决了许多性能瓶颈。铅>

---

因此，听起来您可能会对在Web方法中添加"起始记录号"和"最终记录号"参数的解决方案感兴趣。 (或"页码"和"每页结果")

如果后备存储是sql server(甚至mysql)，这应该不太困难，因为它们内置了对行编号的支持。

尽管如此，您应该能够避免在服务器上进行任何会话管理，避免对结果集进行任何显式缓存，而仅依靠后备存储的缓存来简化您的生活。

---

我有点不同意secretGeek的评论：

That's already happening for you -- it's called tcp/ip ;-) Re-implementing that could be overkill.

有时您可能只想这样做，但实际上只是从UIangular考虑。如果您采用某种方式将数据流式传输到客户端(通过诸如pushlets机制之类的数据)，或者按照您的建议将其分块为页面，则可以在客户端上加载一些非常小的子集，然后使用完整的数据量。

这可以使用户界面更加流畅，快速(从用户的angular来看)，但是您必须评估是否值得付出额外的努力……因为我认为这不会花费不多的工作。 >

---