Effective C#原则34：创建大容量的Web API

Effective C#原则34：创建大容量的Web API2010-12-11 博客园 Wu.Country@侠缘译交互协议的开销与麻烦就是对数据媒体的如何使用。在交互过程中可能要不同的使用媒体，例如在交流中要不同的使用电话号码，传真，地址，和电子邮件地址。让我们再回头来看看上次的订购目录，当你用电话订购时，你要回答售货员的一系列问题：

“你可以把第一项填一下吗？ ”

“这一项的号码是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 ）;