Web服务批量更新

Question

是否有令人信服的理由在.NET Web服务中提供“批量更新”版本的更新方法？

通过HTTP进行多次异步或同步调用是否有相当大的优势？

我的第一个冲动是提供异步调用并在输入组合中包含记录ID，并推迟批量操作作为微优化的要求。或者，我会请求消费者使用迭代循环并进行多次调用。

我不想提出不好的建议。

Answer 1

我认为提供“批量更新”的原因是为了减少数据库服务器上的事务负载。也就是说，如果这不是一个问题，我不会费心去提供一个。

Answer 2

我们提供createRecord（）和createRecordAsync（）/ createRecordCompleted（事件处理程序）

在我们开始注意到它的问题之前，我们想到了创建一个createRecordBatch（）大约10秒的想法。我们的createRecord（）方法除了其他之外还包括会话ID，用户的creatorHandle以及包含所有值的字符串数组。要实现批量加载，我们必须为值创建一个二维数组，一个用于存储creatorHandle的数组和一个会话ID。

即便如此，我们的网络服务只是我们外部供应商和核心应用程序之间的楔子。核心应用程序不支持批量加载。基本上我们一直在做的是模仿我们供应商的批量加载。我们必须将他们的批量数据解析为单独的记录创建。没有必要为我们的用户提供不存在的模拟功能，因为我们不会减少数据库上的任何命中。实际上，处理批量加载的额外工作是将工作从客户端转移到服务器端，这感觉反直觉。

让我们的供应商通过收集数据并对我们的Web服务方法进行多次单独调用来构建多个票证创建的逻辑更有意义。我相信只有其中一个人会进行异步呼叫......其余人都对同步感到满意。