Web服务大规模更新

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

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

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

我不想提出不好的建议。

2010-08-09 Sprague

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

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

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

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

来源

2010-08-09 15:58:17 RavB

我认为有一个createRecordBatch不会有什么坏处，因为在某些时候您的数据库可能会支持它，并且您已经为客户提供了接口，这样，您可以简单地使用“for”来调整createRecordBatch的实现“循环使用数据库批量插入语法。 – Nate 2010-08-09 17:17:46

@Nate Bross我明白了你的观点，但我认为我现在明确地认为，只有在测试中未达到性能目标时才会存在这样的要求 – Sprague 2010-08-09 18:02:33

@Nate Bross您提出了一个非常好的观点......我不得不花好10分钟试试并记住为什么我们裁定这个选项（非常好）。我们不能保证我们设计方法（参数，数据类型）的方式与核心实现一致。我们是中间件，核心系统对我们来说是一个黑匣子。 – RavB 2010-08-09 18:44:20

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

来源

2010-08-09 15:43:40 Nate

我在想，是的，虽然将更新写入单个语句对于此应用程序来说过于复杂。我也在考虑他们担心传输额外的XML标题，但如果他们确实发送了那么多的数据，他们将需要在WCF中摆弄消息缓冲区等。您的回答让我更加倾向于将这一要求推回给用户，作为不成熟的优化。 – Sprague 2010-08-09 15:47:24

Web服务大规模更新

回答

相关问题