1

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

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

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

我不想提出一个糟糕的建议。

4

2 回答 2

1

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

于 2010-08-09T15:43:40.550 回答
1

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

在我们开始注意到它的问题之前，我们玩弄了创建一个 createRecordBatch() 的想法大约 10 秒钟。我们的 createRecord() 方法包括一个会话 ID、一个用户的 creatorHandle 和一个包含所有值的字符串数组。要实现批量加载，我们必须为值创建一个二维数组、一个用于存储 creatorHandle 的数组和一个单个会话 ID。

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

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

于 2010-08-09T15:58:17.823 回答