1

.NET Web サービスで更新メソッドの「バッチ更新」バージョンを提供する説得力のある理由はありますか?

HTTP 経由で非同期または同期の複数の呼び出しを行うことよりも大きな利点はありますか?

私の最初の衝動は、非同期呼び出しを提供し、入力コンポジットにレコード ID を含め、マイクロ最適化としてバッチ操作を提供するという要件に反対することです。または、消費者に反復ループを使用して複数の呼び出しを行うように要求します。

私は悪い提案をしたくありません。

4

2 に答える 2

1

createRecord() と createRecordAsync() / createRecordCompleted (イベント ハンドラー) を提供しています。

createRecordBatch() を作成するアイデアを約 10 秒間試行錯誤した後、問題に気付きました。createRecord() メソッドは、特に、セッション ID、ユーザーの CreatorHandle、およびすべての値を含む文字列配列を受け取ります。バッチ ロードを実装するには、値の 2 次元配列、creatorHandle を格納する配列、および単一のセッション ID を作成する必要があります。

それでも、当社の Web サービスは、外部ベンダーとコア アプリケーションの間のくさびとして機能します。コア アプリケーションはバッチ ロードをサポートしていません。基本的に、私たちが行っていたであろうことは、ベンダーへのバッチ ロードを模倣することでした。バッチ データを解析して個々のレコードを作成する必要があります。データベースへのヒットを減らすことはできないため、存在しないモック機能をユーザーに提供しても意味がありませんでした。実際、バッチ ロードを処理するための余分な作業は、クライアント側から作業を奪い、それをサーバー側に置くことであり、直感に反しているように感じました。

データを収集し、Web サービス メソッドを個別に複数回呼び出すことで、複数のチケットを作成するためのロジックをベンダー自身に構築してもらう方が理にかなっています。そのうちの1つだけが非同期呼び出しを行うと思います...残りは同期に満足しています。

于 2010-08-09T15:58:17.823 に答える
1

「バッチ更新」を提供する理由は、データベース サーバーのトランザクション負荷を軽減するためだと思います。とはいえ、これが問題でなければ、あえて提供しません。

于 2010-08-09T15:43:40.550 に答える