Effective C#原則34：建立大容量的Web API

互動協議的開銷與麻煩就是對資料媒體的如何使用。在互動過程中可能要不 同的使用媒體，例如在交流中要不同的使用電話號碼，傳真，地址，和電子郵件 地址。讓我們再回頭來看看上次的訂購目錄，當你用電話訂購時，你要回答售貨 員的一系列問題：

“你可以把第一項填一下嗎？ ”

“這一項的號碼是123-456”

"您想訂購 多少呢？"

"三件"

這樣的問題一直要問到銷售人 員填寫完所有的資訊為止，例如還要知道你的訂購地址，信用卡資訊，運送地址 ，以及其它一些必須的資訊來完成這比交易。在電話上完成這樣一來一回的討論 還是令人鼓舞的。因為你不會是一個人長時間的自言自語，而且你也不會長時間 忍受銷售人員是否還要哪裡的安靜狀態。

與傳真訂購相比，你要填寫整 個訂購文檔，然後把整個文檔發給公司。一個檔案一次性傳輸完成，你不用很填 寫產品編號，發傳真，然後填寫地址，然後再傳真，填寫信用卡號，然後再發傳 真。

這裡示範了一個定義糟糕的web方法介面會遇到的常見缺陷。當你使 用web服務，或者.Net遠程互動時，你必須記住：最昂貴的開銷是在兩台遠程機 器之間進行對象傳輸時出現。你不應該只是通過重新封裝一下原來在本機電腦 上使用的介面來建立遠程API。雖然這樣是可以工作的，但效率是很低的。

這就有點類似是用電話的方式來完成用傳真訂購的任務。你的應用程式 大部份時間都在每次向通道上發送一段資料後等待網路。使用越是小塊的API， 應用程式在等待伺服器資料返回的時間應用比就更高。

相反，我們在創 建基於web的介面時，應該把伺服器與用戶端的一系列對象進行序列化，然後基 於這個序列化後的文檔進行傳輸。你的遠程交流應該像用傳真訂購時使用的表單 一樣：用戶端應該有一個不與伺服器進行通訊的擴充已耗用時間段。這時，當所用 的資訊已經填寫完成時，使用者就可以一次性的提交這個文檔到伺服器上。伺服器 上還是做同樣的事情：當伺服器上返回到客戶上的資訊到達時，客戶的手頭上就 得到了完成訂購任務必須的所有資訊。

比喻說我們要粘貼一個客戶訂單 ，我們要設計一個客戶的訂購處理系統，而且它要與中心伺服器和案頭使用者通過 網路訪問資訊保持一致。系統其中的一個類就是客戶類。如果你忽略傳輸問題， 那麼客戶類可能會像這樣設計，這充許使用者取回或者修改姓名，運輸地址，以及 帳號資訊：

public class Customer
{
　public Customer( )
　{
　}
　// Properties to access and modify customer fields:
　public string Name
　{
　　// get and set details elided.
　}
　public Address shippingAddr
　{
　　// get and set details elided.
　}
　public Account creditCardInfo
　{
　　// get and set details elided.
　}
}

這個客戶類不包含遠程 調用的API，在伺服器和客戶之間調用一個遠端使用者會產生嚴重的交通阻塞：

// create customer on the server.
Customer c = new Server.Customer( );
// round trip to set the name.
c.Name = dlg.Name.Text;
// round trip to set the addr.
c.shippingAddr = dlg.Addr;
// round trip to set the cc card.
c.creditCardInfo = dlg.credit;

相反，你應該在本機建立一 個完整的客戶對象，然後等使用者填寫完所有的資訊後，再輸送這個客戶對象到服 務器：

// create customer on the client.
Customer c = new Customer( );
// Set local copy
c.Name = dlg.Name.Text;
// set the local addr.
c.shippingAddr = dlg.Addr;
// set the local cc card.
c.creditCardInfo = dlg.credit;
// send the finished object to the server. (one trip)
Server.AddCustomer( c );