交互協議的開銷與麻煩就是對數據媒體的如何使用。在交互過程中可能要不 同的使用媒體，例如在交流中要不同的使用電話號碼，傳真，地址，和電子郵件 地址。讓我們再回頭來看看上次的訂購目錄，當你用電話訂購時，你要回答售貨 員的一系列問題：
“你可以把第一項填一下嗎？ ”
“這一項的號碼是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 );
這個客戶的例子清楚簡 單的演示了這個問題：在服務器與客戶端之間一來一回的傳輸整個對象。但為了 寫出高效的代碼，你應該擴展這個簡單的例子，應該讓它包含正確的相關對象集 合。在遠程請求中，使用對象的單個屬性就是使用太小的粒子(譯注：這裡的粒 子就是指一次交互時所包含的信息量)。但，對於每次在服務器與客戶之間傳輸 來說，一個客戶實例可能不是大小完全正確的粒子。
讓我們來再擴展一 下這個例子，讓它更接近現實設計中會遇到的一些問題，我們再對系統做一些假 設。這個軟件主要支持一個擁有1百萬客戶的在線賣主。假設每個用戶有一個訂 購房子的主要目錄，平均一點，去年有15個訂單。
每個電話接線員使用 一台機器輪班操作，而且不管電話訂單者是否回答電話，他們都要查找或者創建 這條訂單記錄。你的設計任務是決定大多數在客戶和服務器之間傳輸的高效對象 集合。
你一開始可能消除一些顯而易見的選擇，例如取回每一個客戶以 及每次的訂單信息是應該明確禁止的：1百萬客戶以及15百萬(1千5百萬)訂單記 錄顯然是太大了而不應該反回到做一個客戶那裡去。這樣很容易在另一個用戶上 遇到瓶頸問題。在每次可能要更新數據時，都會給服務器施加轟炸式打擊，你要 發送一個包含15百萬對象的請求。當然，這只是一次事務，但它確實太低效了。
相反，考慮如何可以最好的取回一個對象的集合，你可以創建一個好的 數據集合代理，處理一些在後來幾分鐘一定會使用的對象。一個接線員回復一個 電話，而且可能對某個客戶有興趣。在電話交談的過程中，接線員可能添加或者 移除訂單，修改訂單，或者修改一個客戶的賬號信息。明顯的選擇就是取回一個 客戶，以及這個用戶的所有訂單。服務器上的方法可能會是這樣的：
public OrderData FindOrders( string customerName )
{
// Search for the customer by name.
// Find all orders by that customer.
}
對的嗎？傳送到客戶而且客戶已經接 收到的訂單很可能在客戶機上是不須要的。一個更好的做法就是為每個請求的用 戶只取回一條訂單。服務器的方法可能修改成這個樣子：
public OrderData FindOpenOrders( string customerName )
{
// Search for the customer by name.
// Find all orders by that customer.
// Filter out those that have already
// been received.
}
這樣你還是要讓客戶機為每個電話訂單創建一 個新的請求。有一個方法來優化通信嗎？比下載用戶包含的所有訂單更好的方法 。我們會在業務處理中添加一些新的假設，從而給你一些方法。假設呼叫中心是 分布的，這樣每個工作組收到的電話具有不同的區號。現在你就可以修改你的設 計了，從而對交互進行一個不小的優化。
每個區域的接線員可能在一開 始輪班時，就取回並且更新客戶以及訂單信息。在每次電話後，客戶應用程序應 該把修改後的數據返回到服務上，而且服務器應該響應上次客戶請求數據以後的 所有修改。結果就是，在每次電話後，接線員發送所有的修改，這些修改包含這 個組中其它接線員所做的所有修改。這樣的設計就是說，每一個電話只有一次會 話，而且每一個接線員應該在每次回復電話時，手裡有數據集合訪問權。這樣服 務器上可能就有兩個這樣的方法：
public CustomerSet RetrieveCustomerData(
AreaCode theAreaCode )
{
// Find all customers for a given area code.
// Foreach customer in that area code:
// Find all orders by that customer.
// Filter out those that have already
// been received.
// Return the result.
}
public CustomerSet UpdateCustomer( CustomerData
updates, DataTime lastUpdate, AreaCode theAreaCode )
{
// First, save any updates, marking each update
// with the current time.
// Next, get the updates:
// Find all customers for a given area code.
// Foreach customer in that area code:
// Find all orders by that customer that have been
// updated since the last time. Add those to the result.
// Return the result.
}
但這樣可能還是要浪費一些帶寬。當每個已知客 戶每天都有電話時，最後一個設計是最有效。但這很可能是不對的。如果是的， 那麼你的公司應該在客戶服務上存在很大的問題，而這個問題應該用軟件是無法 解決的。
如何更進一步限制傳輸大小呢，要求不增加會話次數和及服務 器的響應延時？你可以對數據庫裡的一些准備打電話的客戶進行一些假設。你可 以跟蹤一些統計表，然後可以發現，如果一些客戶已經有6個月沒有訂單了，那 麼他們很可能就不會再有訂單了。這時你就應該在那一天的一開始就停止取回這 些客戶以及他們的訂單。這可以收縮傳輸的初始大小，你同樣可以發現，很多客 戶在通過一個簡短電話下了訂單過後，經常會再打電話來詢問上次訂單的事。因 此，你可以修改訂單列表，只傳輸最後的一些訂單而不是所有的訂單。這可能不 用修改服務器上的方法簽名，但這會收縮傳輸給客戶上的包的大小。
這 些假設的討論焦點是要給你一些關於遠程交互的想法：你減少兩機器間的會話頻 率和會話時數據包的大小。這兩個目標是矛盾的，你要在這兩者中做一個平衡的 選擇。你應該取兩個極端的中點，而不是錯誤的選擇過大，或者過小的會話。
返回教程目錄
