建立和管理分布式数据服务的基本原则

分布式系统的优点在于用它所构建的应用程序可以重用其它系统的数据和应用程序逻辑。为了设计可供重用的系统，你需要把用经典的三层（表示层、事务层和数据层）结构作为应用程序基础的老观念放到一边，开始考虑集成了多个服务——每个服务都有自己的表示层（或者接口）、事务层和数据逻辑层——的应用程序。

服务的设计

尽管在传统的三层系统中，你习惯于在每一层中都有一个服务，但是你现在要设计的系统需要多个服务（如：一个客户管理服务、一个信用卡服务、一个库存管理服务以及一个订单处理服务）来提供支持。这些服务有着自己的公共接口、事物逻辑和数据访问逻辑。公共接口可以是GUI、HTML或者WS接口。当用在一个应用程序中时，服务可能返回标量、对象或者数据集以供其它服务或者一个应用程序的用户接口所使用。

服务中的核心事务逻辑是由一套.NET类组成的，它们实现了公共接口所宣布提供的功能并管理事务规则（事务规则支配访问和管理过程）。数据访问逻辑是来自多个底层数据源（包括SQL数据库、消息队列、Web服务、legacy程序或者基于COM的系统）的、被事务逻辑所请求的数据的统称。

服务之间只能按照服务在其公共接口中所定义的约定进行对话。一旦例化之后，服务的实例就不应该直接访问彼此之间的状态，但应该让其它服务或者使用它们的应用程序管理它们的状态。但是，如果你要对服务以及（或者）应用程序的状态进行有效的管理，那么在构建体系时你仍然要考虑每个服务所请求数据的位置。

当处理多个服务时，有些服务可能位于其它应用程序范围之内或者甚至是与本机有低速连接的其它机器上，为了获得更快的用户界面响应时间或者减少本地处理时间，需要某种本地数据缓冲。但是除非你巧妙的进行缓冲，相对于在每次调用时都查询远端数据服务的方法，你将花费更多的时间来补偿未命中的缓冲数据——因为缓冲区的数据可能已经“陈旧”了。