我想这个问题很有意思，但我想要一些反馈。目前我正在通过dtos从Web服务构建poco类对象。我预加载所有标量值，并且延迟加载所有集合/数组，当然包括二进制文件。
显然，我这样做是为了改善响应时间，因为这个库是推动Web应用程序的动力。但是，为了保持服务的可重用性，我将每个GET函数规范化为单个动作（S）。因此，例如，从活动目录中获取用户信息就是其中一个（例如，像displayName和department这样的标量值），抓取此人的直接报告是一个单独的，延迟加载的操作。所以会发生什么，当你构建一个对象时，有很多调用服务来构建这个对象。有些页面只需要基本信息，有些页面会调用更多的延迟加载方法甚至是整个对象。我没有看到这个问题，但我想知道的（其他人在工作中已经在批评）是否会出现问题？
我的问题是，我做错了吗？尽管如此，所有输入都是值感谢
答案 0 :(得分：6)
您需要触及的余额是进行HTTP调用的开销，而不是传输大量请求或响应的开销。
没有银弹。例如，如果通过LAN从一个服务器到另一个服务器进行呼叫，则较大的有效载荷不是问题。如果呼叫是从移动设备进行的，那么修剪有效载荷可能会带来很多好处。
开始时的最佳平衡是将Web服务的方法视为工作流程中的步骤。想想“如果我想要实现X，我需要什么数据？”;尝试围绕这些想法确定您的请求响应范围，然后分析结果。这只是一个起点，但它比“每个微小细节的一种方法”或“允许一切的一种方法”更好。
答案 1 :(得分：3)
我没有看到这个问题，但我想知道（其他人在工作中已经在批评）是否会出现问题？
问题是每次调用服务都会产生开销。通过更少，更大的呼叫，您将获得更好的总吞吐量。
这里总是有一个折衷，并达到平衡。较大的呼叫存在吸收超过所需数据的风险，这也浪费了资源。
答案 2 :(得分：1)
我投票支持频率较低的电话。
由于您处于Web上下文中，因此数据从数据存储遍历到您的应用层然后再转移到Web层是一项昂贵的操作，我相信网络遍历占用的资源最多。因此，较少频繁的呼叫（通过Web层中的缓存机制）可以更好地扩展，这来自个人经验。
此外，您定义为“大”的内容取决于您的应用程序使用情况。例如。如果您的大多数用户只看到他们的基本信息，而只有少数几个用户可以进一步查看直接报告，则可以使用2个单独的呼叫。否则，坚持一个。
希望这有帮助。