您对使用Web-Services获取大数据列表有何看法？

Question

我曾与开发人员讨论过使用Web-Services获取数据列表的问题，他们说这取决于网站、商业、博客等的类型。

你对这个问题的看法是什么？在性能方面，使用Web-Service获取大量数据是一种明智的方式吗？

Answer 1

你可以看看Apache Wicket list组件是如何解决这个问题的。

很少有人想要显示一个大列表的全部内容。在某一时刻只有一个页面，并链接到结果集中的其他页面。

第一次调用ws运行查询时，返回所有ID的列表和最初将在客户机上显示的记录的子列表。您可以使用ID列表的大小来创建页面链接。

在客户端，您可以使用ID列表来构建对其他页面的请求。

如果您使用某些会话管理，则ID列表可以存储在服务器上，并且对页面的请求只能包含页码和每页的记录数。

Answer 2

哦..。由于性能问题，我们没有在这里工作，这是因为它是针对CRM类型的应用程序，并且从业务线应用程序中获取打开的案例列表必须在3秒内返回。我们最终直接访问了数据库。

所以我猜这就是问题的答案，应用程序的类型是什么，用户是否参与其中？

如果它的系统到系统-我们有那些-由BizTalk组织-关闭案例列表。因此，我们安排了那些非办公时间，以确保两个用户组的性能都不会受到影响

Answer 3

就我个人而言，我不认为这与应用程序本身有太多关系(尽管面向用户的应用程序与机器间的应用程序有不同的要求，而且一些面向用户的应用程序会比其他应用程序更优雅地容忍延迟)；真正的问题是，将我的数据发送到客户端的最佳方式是什么？这是一个答案总是会有一些变化，“嗯，这取决于。”

就我而言，我可以说，对于面向公众的面向用户的应用程序，一般来说，应该避免或至少避免“大列表”，这不是因为它们本质上是邪恶的，而是因为它们会影响用户体验(客户端应用程序在检索或处理大型数据集时可能会挂起)，它们不能很好地扩展(如果您的主页为每个请求(无论是不是服务器缓存的)向下推送大量的SOAP外壳，那么随着流量的增加，您将会遇到麻烦)，等等。根据项目的进展情况，您可能会发现需要重写以支持增加的负载，或者增强滞后的性能或响应能力，对于面向服务的应用程序来说，这可能是一项重要的、不那么有趣的工作。

也就是说，我也以这种方式编写了很多自己的服务层，在那些对我来说响应性并不重要的项目上(例如，个人项目)，或者当我真的不希望有那么多负载时，因为它们可以快速开发、部署和维护。用户确实受到了启动的冲击，但这种冲击也可以通过良好的设计来掩盖，并且将大量数据放在客户端上，特别是当它不经常更改时，可能会很方便。

所以很难用这种或那种方式来说；有时很好，有时不好--“这取决于”。在不了解您的特定需求的情况下，我可能会建议您继续使用大列表锤子编写一些简单的代码，使用真实(或接近真实)的数据，进行一些测量，推断它们，看看事情是什么样子。你可能会发现没什么好担心的，你最不想做的事情就是陷入一个不必要的复杂设计中，仅仅因为StackOverflow上的一群人告诉你“大清单不好”。;)