Effective C# 原則 34：設計粗粒度 Web API，減少遠端往返開銷

電話訂購 vs. 傳真訂購：API 設計的隱喻

Web 服務或 .NET 遠端處理中，跨機器物件傳輸是最昂貴的操作。將本地介面直接封裝為遠端 API 雖可運作，但效率極低——猶如用電話逐筆詢問填寫傳真單，頻繁等待網路回應。

正確策略：一次傳輸完整資料文件

客戶端應在本地組裝完整物件圖，填妥所有資料後一次性送至伺服器；伺服器處理完畢後，一次回傳所需結果。這類似「填妥傳真單一次發送」。

反面教材：細粒度遠端呼叫

// 伺服器端建立客戶
Customer c = new Server.Customer();
// 多次跨網路往返設定屬性
c.Name = dlg.Name.Text;           // 第 1 次往返
c.shippingAddr = dlg.Addr;        // 第 2 次往返
c.creditCardInfo = dlg.credit;    // 第 3 次往返

正確示範：本地組裝，單次傳輸

// 客戶端本地建立並填充
Customer c = new Customer();
c.Name = dlg.Name.Text;
c.shippingAddr = dlg.Addr;
c.creditCardInfo = dlg.credit;
// 單次往返送至伺服器
Server.AddCustomer(c);

進階：依業務情境決定資料粒度

單一 Customer 物件未必是最佳傳輸單位。以百萬客戶、千萬訂單的呼叫中心為例：

• 錯誤：一次載入所有客戶與訂單（資料量過大）。
• 改進：僅載入來電客戶的未完成訂單。
• 再優化：依區號預載該區客戶與訂單，通話結束時批次同步異動。
• 統計輔助：停止載入半年無訂單的沉睡客戶；僅傳輸最近 N 筆訂單。

核心原則：在「往返次數」與「封包大小」間尋找平衡點，避免極端細粒度或粗粒度設計。