WEB开发网
开发学院软件开发C语言 Effective C# 原则34:创建大容量的Web API 阅读

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

 2009-02-19 08:15:58 来源:WEB开发网   
核心提示: public OrderData FindOrders( string customerName ){// Search for the customer by name.// Find all orders by that customer.}对的吗?传送到客户而且客户已经接收到的订单很

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个月没有订单了,那么他们很可能就不会再有订单了。这时你就应该在那一天的一开始就停止取回这些客户以及他们的订单。这可以收缩传输的初始大小,你同样可以发现,很多客户在通过一个简短电话下了订单过后,经常会再打电话来询问上次订单的事。因此,你可以修改订单列表,只传输最后的一些订单而不是所有的订单。这可能不用修改服务器上的方法签名,但这会收缩传输给客户上的包的大小。

这些假设的讨论焦点是要给你一些关于远程交互的想法:你减少两机器间的会话频率和会话时数据包的大小。这两个目标是矛盾的,你要在这两者中做一个平衡的选择。你应该取两个极端的中点,而不是错误的选择过大,或者过小的会话。

上一页  1 2 3 4 

Tags:Effective 原则 创建

编辑录入:爽爽 [复制链接] [打 印]
赞助商链接