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

Question

我与开发人员讨论了如何使用Web服务获取数据列表， 他们说这取决于网站的类型，商业，博客等。

您对此主题有何看法？ 使用Web服务获取大数据列表是一种明智的表现方式吗？

Answer 1

您可以查看Apache Wicket列表组件如何解决此问题。

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

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

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

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

Answer 2

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

我想我的答案是什么是类型关闭应用程序，是否涉及用户？

如果它的系统系统 - 我们有那些 - 由BizTalk协调 - 封闭的案例列表。它只是可用的系统资源 - 所以我们安排那些非办公时间以确保两个用户组都没有性能损失

Answer 3

就我个人而言，我认为它与应用程序本身并没有那么多关系（尽管面向用户的应用程序肯定会有机器间应用程序的不同要求，而且一些面向用户的应用程序将容忍滞后更多比其他人优雅）;问题是，将数据提供给客户端的最佳方法是什么？这个答案总是会有一些变化，“嗯，这取决于。”

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

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

因此很难说出这样或那样的方式;有时它很好，有时不是 - “这取决于。”在不了解您的特定要求的情况下，我可能会建议您继续使用大名单锤子编写简单的代码，使用真实（或接近真实）的数据，进行一些测量，推断它们，并查看事物的外观。您可能会发现没有什么可担心的，而您最不想做的就是陷入不必要的复杂设计中，因为StackOverflow上的一群人告诉您“大名单很糟糕”。 ;）