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服務大規模更新

回答

相關問題