データを複数のテーブルに挿入するなど、フォームの送信時にサービス側で複数の操作を実行する必要があるシナリオでは、大きなデータ契約を持つ単一のサービス呼び出しを行うか、複数の小さなデータ契約を持つ複数のサービス呼び出しを行う方がよいでしょうか。
私の質問をさらに詳しく説明するために、例を挙げて、「会議」を追加するためのフォームがあるとしましょう。このフォームを使用すると、ユーザーは会議に関する情報（ConferenceName、ConferenceDate、....、プレゼンター、スポンサーなど）を入力できます。一部の情報は会議テーブルに挿入されるため、一部はConferencePresentersテーブルに、一部はConferenceSponsorsテーブルに挿入されます。 。では、大規模なデータコントラクトを使用した単一の呼び出しを使用してすべてのデータをWebサービスに送信するか、複数のデータコントラクトを使用して個別のサービス呼び出しを行う方がよいでしょうか。
大規模なデータ契約または複数のサービスコールがある場合、2つのうちどちらがより高価ですか？
より適切に定量化するのは難しいです。ただし、帯域幅、アトミック性、サービス編成などを考慮することができます。
帯域幅については、各リクエストに時間がかかるため、1つの大きなチャンキーリクエストの方がネットワーク上で高速になります。さらに、クライアントは、（より適切な単語がないために）子が作成される前に、さまざまなエンティティが作成されるまでn*latencyを待機していません。
サービスをサポートするデータベースがあり、トランザクションでこの操作を実行できると仮定します。おしゃべりなサービスを選択した場合は、ロールバックなどを自分で管理することになります。
考慮すべきもう1つの重要なことは、サービスAPIがどのように設計されているかです。分厚い操作は意味がありますか？オプションの操作でチャンクが大きくなっている場合は、それらを除外できます。2つのAPIが常に一緒に呼び出され、組み合わせるのが理にかなっている場合は、それらを組み合わせます。
したがって、大規模なデータコントラクトを使用すると、前述のような操作（スポンサーとの会議の作成など）のパフォーマンスが向上することがわかりますが、パフォーマンスの向上は、このような操作のトレードオフに見合う価値があります。大きくて特定のAPI呼び出し。
この問題は、アーキテクチャの観点からも見ることができます。
あなたにはサービスがあります：
この観点から、単一の操作が必要です。
分厚い、毎回、または可能な限り分厚い。経験則により、会話は可能な限り大きくなり、もみ殻が削減されます。