我想这个问题有点加载，但我想要一些反馈。目前我正在通过 dtos 从 Web 服务构建 poco 类对象。我预加载所有标量值，并延迟加载所有集合/数组，当然包括二进制文件。
显然，我这样做是为了缩短响应时间，因为这个库是 Web 应用程序的驱动力。但是，为了保持服务的可重用性，我将每个 GET 函数标准化为单个操作 (S)。因此，例如，从活动目录中获取用户信息是一个（例如 displayName 和部门等标量值），而获取此人的直接下属是一个单独的、延迟加载的操作。那么发生的情况是，当您构建一个对象时，会多次调用服务来构建这个对象。有些页面只需要基本信息，有些页面会调用更多的延迟加载方法甚至整个对象。我认为这没有问题，但我想知道（其他工作人员已经在批评）这是否会成为问题？
我的问题是，我做错了吗？不过，所有输入都值得赞赏。谢谢
您需要平衡的是进行 HTTP 调用的开销与传输大型请求或响应的开销。
没有银弹。例如，如果通过 LAN 从一台服务器向另一台服务器进行呼叫，那么更大的有效负载就不是什么大问题了。如果呼叫是通过移动设备进行的，那么修剪有效负载可能会带来很多好处。
开始时最好的平衡是将 Web 服务的方法视为工作流中的步骤。想想“如果我想实现X，我需要什么数据？”；尝试围绕这些想法确定您的请求响应范围，然后分析结果。这只是一个起点，但它比从“每个微小细节的一种方法”或“一种允许一切的方法”开始要好。
我认为这没有问题，但我想知道（其他工作人员已经在批评）这是否会成为问题？
问题是对服务的每次调用都会产生开销。您将通过更少、更大的调用获得更好的总吞吐量。
这里总是有一个权衡，并达到一个平衡。较大的调用可能会提取比所需更多的数据，这也浪费了资源。
我投票支持不太频繁的大电话。
由于您处于 Web 环境中，数据从数据存储区遍历到应用层，然后再到 Web 层是一项昂贵的操作，我相信网络遍历占用的资源最多。因此，不太频繁的调用（通过 Web 层中的缓存机制）可以更好地扩展，这来自个人经验。
此外，您定义为“大”的内容取决于您的应用程序使用情况。例如，如果您的大多数用户只看到他们的基本信息，而只有少数选择进一步进入直接下属，您可以使用 2 个单独的调用。否则，坚持一个。
希望这可以帮助。